#1592 Phase 1 — 데이터 공개 영역 전수 대상표
작성: 2026-09-14, 보조 작업자 /root/publication_inventory. 조사 checkout: work/app1592, 문서: work/docs1592. 제품 코드 변경·원격 실행·원격 쓰기 없음.
최종 목표와 이 표의 판정 범위
모바일·PC의 모든 기존 입력은 즉시 의미 있는 화면 반응을 내고, 필요한 데이터 영역은 스켈레톤으로 남으며, 현재 owner·선택·저장 결과에 맞는 필수 데이터와 계산이 모두 준비된 상태를 한 번에 공개한다. 대기·오류·빈 결과를 구분하고, 재방문·연속 입력·계정 전환·실패에서 같은 계약을 지킨다. 이 조사표는 홈·달력·피드·그룹·검색·프로필·기록/종목 상세의 데이터 공개 연결을 담당한다. 입력/탐색/편집 열기와 통계 공통 상태/리포트 코어는 주 작업의 다른 산출물과 합쳐 전체 범위를 판단한다.
아래의 ‘현재 동작’은 실제 소스의 공급→선택→binding→UI 분기 확인이다. 이 조사에서 브라우저·사용자 운영 화면·성능 실측이나 테스트 실행은 하지 않았다. 연결이 없거나 소스가 먼저 공개하는 사실과 사용자 환경에서 결함을 재현했다는 주장은 구분한다. 기존 검사 파일은 재사용 가능한 검증 기반이며 이번 후보 통과 증거가 아니다.
읽은 지침/계약: 앱·문서 최상위 AGENTS.md, 전역 설계·작업 원칙, docs/contracts/shell-frames.md, feature-resource-integration.md(특히 A11·A15), desktop-screens-props.md, feed-props.md, group-props.md, day-summary-props.md, docs/updates/2026-09-11-home-complete-reveal.md. 과거 계약의 ‘일단 이전 데이터 유지’ 또는 ‘독립 로딩’은 #1592의 최종 사용자 지시와 대조해야 할 기존 정책이다.
등록 화면 대조
src/react/controllers/screenKinds.ts의 등록은 다음 19종이다. 이는 깊이 화면이며 루트 탭은 별도로 대조했다.
| 등록 kind | 실제 공개 연결/담당 |
|---|---|
| menu | 전역 드로워, 입력/탐색 산출물 |
| workout | 전역 운동/편집, 입력/편집 산출물 |
| legal | 전역 법률 문서, 입력/탐색 산출물 |
| session | 본 표 S1/S2: MobileSessionOverlayBinding |
| daySummary | C2: MobileDaySummaryBinding |
| prDetail | R1: MobilePrDetailBinding |
| friendScope | F2–F5: MobileFriendScopeBinding |
| friendSession | F6: MobileFriendSessionBinding |
| journalMonth | C3: SessionScreen의 월 overlay + journal selection |
| journalDay | C2/C3: SessionScreen의 일/주 overlay + journal selection |
| homeReport | 리포트 코어 산출물, MobileHomeReportOverlay → MobileReportBinding |
| prTape | PR 목록/기록 산출물과 R1 연결 확인 대상 |
| prList | PR 목록/기록 산출물과 R1 연결 확인 대상 |
| groupLounge | G2: MobileGroupBinding → UiGroupInfoScreen |
| groupBoard | G3: MobileGroupBinding → UiGroupScreen |
| groupSession | G5: MobileGroupBinding → UiGroupSessionOverlay |
| groupComposer | 입력/편집 산출물, 본 표는 하부 보드 데이터 준비만 다룸 |
| groupBoardExercise | G4: UiGroupScreen 내부 종목 기록 |
| recordsTool | PR 도구 산출물, MobileRecordsToolsBinding |
모바일 루트 binding은 home·calendar·feed·group·volume·search·profile·pr 경로이며, PC src/react/desktopApp.tsx:36–43은 home·calendar·logtable·search·favgroups·volume·pr·profile 8개 binding이다. PC에는 독립 feed·social group·friendScope 탭/binding이 없다. PC 피드는 홈 컬럼(H3/F1)이며 favgroups는 즐겨찾기 종목 그룹으로 소셜 그룹과 다르다. 기존 PC에 없는 모바일 기능을 신설하는 것은 본 트랙의 전수 적용 의미가 아니다.
공개 단위 대상표
경로는 앱 checkout의 src/react/ 기준이다. 합격 단위는 ‘본문에 같은 의미를 설명하는 값들이 함께 완성되어야 하는 영역’이다. 서로 독립적인 영역과 본문 밖 입력/닫기까지 한 대기 상태로 묶지 않는다.
| ID·플랫폼·영역 | 필수 입력과 현재 실제 공개 경로 | 최종 공개 묶음/캐시 유효성 | 현재 근거·연결 또는 검증 잔여 |
|---|---|---|---|
| H1 모바일 홈 전체 본문 | homeDashboardBinding.ts:69–70 → MobileHomeBinding.tsx:115–116 → ui/mobile/screens/HomeScreen.tsx:219. HOME_DASHBOARD + PR 개요(기준표 포함) + owner 즐겨찾기 hydration | 레벨·누적량·주요 종목·기록·등급·첫 보드. 현재 owner·홈 기준일·적용 세대가 같은 필수 묶음 | 기존 complete-reveal 연결 있음. homeBootstrapPending은 loadingData && !HOME_DASHBOARD, homePrSectionsPending은 favorites pending 또는 PR phase loading만 봄. 데이터 존재만으로 invalidated/pending 저장 적용까지 완료를 보장하는지는 통계 공통 상태와 합쳐 확인 필요. PR error에서 본문을 성공으로 공개하지 않는지도 추가 대조 필요 |
| H2 PC 홈 KPI·주간·연간·PR 카드 | DesktopHomeBinding.tsx:36,58–87,142 → DesktopHomeScreen.tsx:681. desktopHomeProjection이 홈·plans·PR·yearActivity를 조합 | KPI/연간 활동 관련 값은 홈 기준일·세대와 연도 조각 일치. PR 카드 묶음은 PR 기준표 준비 후 공개 | PC binding은 homePrSectionsPending을 받지 않고 homeBootstrapPending만 전달. 홈이 있으면 PR/yearActivity 등은 투영되는 대로 공개된다. 모바일 complete-reveal와 연결 차이 확인. 연도 조각은 이미 homeYearActivityResource 선택자가 홈 기준일·적용 세대를 대조하고 더 앞선 응답이면 홈 재조정함. UI 공개 신호까지 연결 필요 |
| H3 PC 홈 피드 컬럼 | DesktopHomeBinding.tsx:143–146 → DesktopHomeScreen.tsx:649–652,697. feed page 상태·posts | 최초 피드 페이지 본문/카드별 KPI·종목·작성자. 추가 페이지는 새 페이지 영역만 준비 처리 | 최초 idle/loading와 빈 결과는 overlay로 구분, error 분기 있음. 데이터가 있는 refresh는 기존 posts 유지. 무효화 후 공개 계약 및 추가 페이지 실패/대기 종료를 별도 확인 |
| H4 모바일/PC 홈 날짜 상세 | 모바일 MobileHomeBinding의 요청 상태 → HomeScreen.tsx:466–470; PC DesktopHomeBinding.tsx:90–128 → homeDayModal | 선택 날짜의 세션 목록·fullById·합계; 완성 일 응답 | 두 플랫폼 모두 onStart 즉시 빈 modal/상태, onSuccess에 sessions+fullById 함께 적용. homeDayDetailCoordinator가 새 선택·close·owner/탭 변경 후 늦은 응답 거부. 모바일은 텍스트 대기 안내, PC는 section overlay이므로 #1592 스켈레톤 계약으로 표현 연결 필요. 기존 회귀 기반 충분 |
| C1 모바일/PC 달력 월 격자·월 합계 | calendarReadModelStore → controller projection → calendarViewBinding → M MobileCalendarBinding.tsx:40, D DesktopCalendarBinding.tsx:77–79 | owner·월·기준 세대의 월 summaries + 날짜별 행/합계. 격자 chrome과 월 이동은 즉시 | 모바일 pending은 !calendarHasVisibleMonth; hasMonth는 Boolean(resource.peek)라 무효화된 사본도 존재로 셈. 모바일 SessionScreen.tsx:141은 월 통계 줄만 skeleton이고 격자 데이터는 그대로 렌더. PC는 foreground/loading month bands가 있으나 resource validity 자체는 별도 전달되지 않음. publishModels가 peek(낡은 사본 포함)로 map을 계속 발행하므로 무효화 시 공개 정책 연결 필요 |
| C2 모바일/PC 선택일 요약·상세 | calendarReadModelStore.loadDay → calendarReadModelController → 모바일 MobileDaySummaryBinding, PC DesktopSessionDetailParts | 선택일 월 요약 카드 + 상세 종목·세트 + 서버 합계. 동일 날짜의 필수 상세가 다 준비된 상태 | store는 현재 선택 revision/owner·abort를 지킴. 그러나 selectedDayLoadingDate는 !snapshot.data 때만 세움. 모바일 daySummary binding에 load/error 상태 prop이 없음. 월 lite는 _calendarDetailPending로 세트만 skeleton, 종목명이 이미 노출되는 기존 계약. PC 선택일 loader는 존재. 재조회/실패의 명시 상태와 묶음 공개 확인 필요 |
| C3 모바일 주/월 드로어·PC 주/월 모달 | useCalendarJournalSelection.ts + calendarReadModelController.summarizeCalendarRange + PC DesktopCalendarBinding | 선택 범위의 완성된 서버 합계·포함 날짜 세션/세트. 데이터만 다른 범위가 섞이지 않아야 함 | ensureCalendarRangeData는 effect에서 시작, binding에 범위 ready/error가 없음. range 없을 때 controller는 일별 서버 합계를 합산해 먼저 표시. 이는 코드의 명시된 기존 폴백(값 동일 가정)이며 이번 계약에서는 최종 묶음 완료 기준을 세워 검증해야 함. 인접 월 미적재/invalidated/요청 실패 시 합계가 완성값처럼 보이는지 재현 필요 |
| F1 모바일 피드·PC 홈 피드 | feedResource.select → MobileFeedBinding/desktop projection → FeedScreen/DesktopHomeScreen | page cursor가 같은 완성 카드 묶음. 작성자 사진 서명·카드 KPI/종목 값은 domain 응답에서 완성 | owner/target/limit/cursor key, 중복 제거/200행 제한, refresh+append 경합 시 새 first cursor 사용, denied면 이전 카드 제거. 첫 page 없으면 skeleton/error 있음. first invalidated라도 items는 유지되어 refresh 중 기존 본문 공개됨. 수정/삭제 영수증의 필수 무효화는 공통 publication 정책과 대조 필요 |
| F2 모바일 친구 홈 | friendScopeStore dashboard/pr/favorites → MobileFriendScopeBinding.tsx의 friendHome → AnyUiHomeScreen | 친구 owner/target + dashboard·PR 기준표·즐겨찾기 모두 준비한 홈 본문 | M 홈 재사용으로 세 가지 status==='loading' 동안 skeleton. store status는 data 있으면 ready로 파생해 invalidated/inflight를 숨길 수 있음. error일 때 null overview/빈 favorites를 넘기며 skeleton이 해제됨. 오류를 빈 친구 기록으로 공개하지 않게 최종 상태 계약 필요 |
| F3 모바일 친구 달력·날짜 | friendScopeStore calendar/day/session resource → MobileFriendScopeBinding | 대상 친구/월/일이 맞는 월 데이터 및 선택일 전체 세션 상세. 월/일은 독립 단위 | 월 pending은 idle/loading, 월 error는 빈 map·0합계가 됨. day ready/error 전에는 lite + _calendarDetailPending; error 종료 후 제목만 카드(토스트)로 처리하는 기존 계약. 날짜 revision/방문 취소가 있음. 실패/정상 빈 상태 분리와 최종 본문 공개 필요 |
| F4 모바일 친구 피드 | shared feedResource + target → MobileFriendScopeBinding → FeedScreen | F1과 같음; 친구 target는 독립 | shared cache/dedup 이용. 추가 로딩은 기존 items 있으면 status ready/loadingMore로 변환. 최초 loading은 boolean 전달해 skeleton 유지됨. 필수 refresh/error validity는 F1과 같은 연결 필요 |
| F5 모바일 친구 리포트 | friendScopeStore.report → MobileReportDesignBinding | 대상 친구·기간·데이터 세대 및 리포트 파생 묶음 | 리포트 코어 담당에 포함. pending은 report.status !== ready, dataStatus는 error/ready로 전달됨. 원본 status가 data 존재만으로 ready를 만들 수 있는 점을 함께 대조 |
| F6 모바일 친구 세션 상세 | friendScopeStore.openSession → MobileFriendSessionBinding → UiStackSessionOverlay | 대상 친구·session id·완성 source | source 없을 때 skeleton, ready source만 full 변환. close/new target에 visit abort. 실패 시 source null/close+toast이나 navigation stack의 실제 해제까지 별도 검사 필요. PC에는 이 binding 없음 |
| G1 모바일 그룹 목록·초대·미니 보드 | groupStore.listPayload/seedFromBootCache/refreshList → MobileGroupBinding.tsx:151–166 | owner·today 목록 응답의 그룹/초대/미니 보드 | 무자료 idle/loading만 skeleton. boot seed는 stale이지만 sliceStatus는 data 있으면 ready. 데이터 있는 list error도 기존 목록 유지하고 UI는 empty error만 표시. 유효 캐시와 필수 갱신 대상 구분 필요. 소셜 그룹 PC 없음 |
| G2 모바일 그룹 라운지 | loadLounge + loadAttendanceMonth → MobileGroupBinding.tsx:181–207 → UiGroupInfoScreen | 라운지 신원/멤버/공지/채팅은 한 payload 묶음. 출석 달력·출석왕은 같은 월 attendance의 별도 묶음 | 라운지 status를 UI에 전달하지 않음: summary group + 빈 members/notices/chat가 먼저 전달 가능. attendance는 loading/error 분리 및 retry 존재하지만 텍스트 대기. owner/group/month key와 visit abort 있음. 라운지 공개 boundary·오류 연결 필요 |
| G3 모바일 그룹 화이트보드 | groupStore.loadBoard의 board + days 병렬 요청 → getSnapshot → MobileGroupBinding.tsx:208–226 | 보드 내용·좋아요·댓글은 board payload; 완료 인원·완료 행·종목별 기록은 days payload로 같은 의미의 독립 영역 | groupState.board.status는 board snapshot만 평가. days의 loading/error는 GroupState에 없음. board 완료 후 days가 미도착하면 완료 0/빈 행을 본문으로 표시. UI loading은 board만 가리므로 데이터 공개 묶음/별도 준비 상태 연결 필요. 새 날짜 선택은 key·abort로 늦은 응답 격리 |
| G4 모바일 보드 종목 기록·월 표시 | groupBoardExercise는 groupExerciseRecords를 daySessions에서 투영; month marks는 loadBoardMonthMarks | 기록 영역은 선택 board date의 days 완성 후 공개. 달력 표시는 요청 month의 marks 완성 후 공개 | days readiness 부재는 G3 공유. month marks 데이터는 여러 resource에서 합치지만 로딩/error prop이 없음. 기존 표시를 유효로 판단할 기준과 empty 구분 필요 |
| G5 모바일 그룹 완료 세션 상세 | openDoneSession → resource detail → MobileGroupBinding.tsx:229–245 | group·session id 완성 source | ready && source 전까지 skeleton. owner scope/visit abort 있음. 실패 시 detail target를 close하고 toast, 실제 stack의 자동 동기화 확인 필요. 그룹 권한 실패 시 이전 데이터 제거 정책 보존 |
| Q1 모바일 종목별 세트 검색 | MobileSetSearchBinding → buildMobileSetSearchCatalog/Selection → SetSearch.tsx:79–105 | 종목 catalog + 해당 세션 검색 인덱스의 전체 결과 및 후기. 현재 선택 id와 완료 인덱스 일치 | 입력 id는 즉시 선택; loading이면 결과 감춤. 표현은 텍스트 대기이며 skeleton 아님. catalog 준비 상태/error prop 없음. PR selectedExercise history 폴백이 사용됨. 로딩 종료와 인덱스 완성/실패 구분 필요 |
| Q2 PC 세션 검색 | DesktopSearchBinding.tsx:34–36 → UiDesktopSearchScreen | 전체 검색 인덱스와 필터 결과·카운트를 함께 공개 | binding은 loading/initialLoading 전달, UI 함수는 받지 않음(DesktopSearchScreen.tsx:187). 결과 0개와 빈 상태를 항상 렌더. 실제 배선 누락 확인. 성공/빈/실패·카운트까지 같은 boundary 필요 |
| P1 모바일/PC 프로필 기본·신체·인입 요약 | auth profile → profileResource → profileProjection → MobileProfileBinding/DesktopProfileBinding | 기본 신원은 auth 완료값; workspace 신체 값·최근 인입 요약은 별도 완성 묶음. owner epoch/필드별 확정 쓰기 | profile resource는 beginChange로 field revision, confirmed write로 오래된 workspace read 무효화. UI에 profile workspace readiness 없음. projection은 workspace 없으면 {}로 null body/빈 인입을 만듦. 초기 auth가 workspace를 실제 항상 포함하는지는 통합 부팅 경로로 확인 필요; 이 조사만으로 결함 단정 안 함 |
| P2 모바일/PC 연결 계정·내 커스텀 종목 | socialIdentityController/customExerciseStore → Profile binding → Profile UI | 각 조회는 기본 프로필과 별도 영역, 해당 owner의 연결 현황/종목 목록 | 양쪽에 loading/error 전달, 화면은 로딩 문구 행과 오류를 사용. 공통 skeleton boundary로 표현 연결. 확정 쓰기 중 버튼 상태와 조회 결과 공개는 구분해 유지 |
| P3 모바일 차단 목록 | moderationStore → MobileProfileBinding → ProfileScreen.tsx:213–226 | 현재 owner 차단 목록 | loading/ready/error 표시가 이미 분리됨; 대기는 텍스트. unblockingId 별도. PC profile에는 차단 목록 binding 없음 |
| S1 모바일/PC 완료 기록 상세 | sessionDetailStore.openCompletedWorkoutDetail → MobileSessionOverlayBinding/PC calendar detail | 현재 owner·session id·revision의 full detail + 표시 계산 | await 전 selected=null/pendingId/stack 설정. source 완성 후 full 투영, latest request+owner 가드. M source null은 skeleton, PC pending 모달에 section overlay. 단, 요청 실패 때 pendingId만 해제하고 M stack이 남으면 source null skeleton이 계속 보이는지 실제 스택 흐름 검사 필요 |
| S2 모바일/PC 계획 상세 | sessionDetailStore.openPlannedWorkoutDetail → 같은 UI | 카드 updatedAt과 detail revision이 일치하는 완성 계획 | store는 상세 필요 시에도 먼저 lite를 full 변환하여 selectedSession에 넣음. M overlay는 pendingId를 받지 않고 session 존재로 본문 공개. PC도 selectedSession 우선 렌더 분기를 확인해야 함(DesktopSessionDetailParts.tsx:607–611). 현재 선택 카드 제목과 완성 본문 경계 분리 필요. 확정 로컬 대기 저장은 완성 로컬 데이터로 공개하되 sync 상태 보존 |
| R1 모바일/PC 종목 상세·PR 히스토리 | prExerciseQueryBinding/prExerciseDetailResource → prProps.selectedExercise, prExerciseStatsStatus → MobilePrDetailBinding/DesktopPrBinding | owner·exercise·기간·기준 세대의 summary/year/history/records 조각과 계산. 선택 이름/뒤로는 별도 | selectedExercise 없으면 M skeleton, 있으면 StatValueStatusContext로 수치 처리. PC detailLoading은 기존 계약상 aria-busy만. 실제 fragment 준비·무효화 연동과 차트/목록 전면은 통계 코어 담당 결과와 결합 필요. 현 검사는 prExerciseStaleData.browser가 핵심 기반 |
공통 원인 후보와 구현 연결 제안
- 데이터가 있음과 공개해도 됨이 섞인 지점을 우선 분리한다.
resource.peek는 이전 데이터를 보유할 용도로 유지하되, 공개 가능 여부는 snapshot status·current key·필수 적용 세대·오류로 판단한다.groupStore.sliceStatus,friendScopeStore.status,calendarReadModelStore.hasMonth, 홈 bootstrap의 존재 판정이 실제 후보이다. 보유 데이터를 일괄 지우는 방식은 복구·유효 재방문 이점을 잃으므로 채택 이유가 없다. - feature마다 raw DTO 준비 조건을 공통 공개 boundary에 넘긴다. UI는 서버/캐시를 읽지 않고
pending | ready | error와 완성 view를 받는다. 기존 화면의loading표시에 타이머만 추가하는 방식은 누락된 데이터나 무효화를 해결하지 못한다. - G3 board와 daySessions는 요청을 직렬화할 필요가 없다. 병렬 조회를 보존하고, 완료자/종목 기록을 days의 준비 상태로 감싸거나 동일 공개 의미로 확정된 묶음이면 all-ready로 공개한다. 개별 숫자를 0으로 채우거나 days 오류를 빈 완료 목록으로 바꾸지 않는다.
- 달력의 월·일·범위 resource는 이미 서로 다른 키가 있다. 공개 단위마다 현재 범위에 포함된 필수 resource의 validity를 조합하여 전달한다. 같은 달·날짜 캐시가 있다 해도 무효화 시점부터 성공 본문을 가려야 하는 경우와, 변경과 무관한 유효 캐시 재사용을 구분한다. 데이터 값이 우연히 같다는 이유로 선공개를 검증 통과시키지 않는다.
- 검색은 마지막 페이지까지 기다려 한 번 적용하는 현재 구현이 있다(
remoteDataController.ts:1923–1979, 최대 40페이지). 공개 연결은 단순하지만 전체 세션 수에 따른 대기 시간이 별도 주요 불확실성이다. 이번 최종 성능 기준으로 대규모 인덱스 대기를 측정하고 해결안을 선택해야 하며, 상한에 걸린 부분 결과를 ‘전체 검색 준비 완료’로 표시하지 않아야 한다. 새 서버 검색 설계까지 자동 확장하지 않고 측정 결과와 승인 범위를 따른다. - 실패 완료는 skeleton 종료와 동시에 명시 오류를 공개한다. source=null이 곧 skeleton인 상세 UI는 idle/loading/error를 구별할 prop이 필요할 수 있다. 모달 전체를 닫는 기존 복구 정책을 유지한다면 실제 navigation stack까지 닫힌 증거로 검증한다.
- 프로필 기본 신원·연결 계정·내 종목·차단 목록은 다른 독립 영역이다. 전체 프로필을 가장 느린 부가 조회에 묶지 않고 각 영역의 완성값·실패를 공개한다. 데이터 준비 중에도 설정 열기·닫기 등 입력은 계속 사용 가능해야 한다.
검증 대상과 기존 기반
각 항목은 실제 store/controller/binding/UI를 함께 연결하고, 응답 순서를 외부에서 붙잡아 공개 전후를 검사해야 한다. UI에 ready prop만 넣는 검사는 공급원 누락을 잡지 못한다.
| 대상 | 재사용 가능한 기존 검사 파일 | #1592에서 추가로 증명할 내용 |
|---|---|---|
| 홈 본문 | tests/react/homeCompleteReveal.browser.mjs, homeBootLoadingOrder.test.mjs, prHomeRankHydration.test.mjs, homeYearActivityResource.test.mjs, homeFragmentCoordination.test.mjs | 모바일/PC 동시 조건. 부팅 각 응답 순서·이미 보이는 캐시 무효화·저장 세대 대기·오류·유효 warm hit. 모든 숫자/등급/본문의 실제 DOM 공개 시점 |
| 홈 날짜 | homeDayDetailCoordinator.test.mjs, tests/browser/a15/home.spec.mjs | 모바일과 PC 요청 시작 직후 skeleton, 마지막 선택·close·owner switch, 실패 종료. 실제 UI 반응 시간 |
| 달력 | calendarReadModelStore.test.mjs, calendarReadModelResources.test.mjs, calendarMonthLoadSignal.test.mjs, calendarExactSummaryProjection.test.mjs, calendarProjectionByMonth.test.mjs, calendarPendingMutationOverlay.test.mjs | 월 존재하지만 invalidated, 선택일 기존 데이터 재조회, range 일부 월 미적재, range RPC 지연, 오류/빈 구분, 합계·상세 공개의 원자성. PC/M 실제 binding 필요 |
| 피드/친구 | feedResource.test.mjs, friendScopeStore.test.mjs, feedSocialStore.test.mjs, feedPullRefresh.test.mjs, followingFeed.test.mjs, feedSessionOverlay.test.mjs | 첫 page/refresh/append 구분, 필수 변경 무효화 즉시 가림, 친구 dashboard/pr/favorites 순서, 권한 실패 후 구자료 없음, 각 화면의 error 표현 |
| 그룹 | groupResourceLifecycle.test.mjs, groupInteractionsStore.test.mjs, groupScreens.test.mjs, groupBoardDateNav.test.mjs, groupComposerContinuity.browser.mjs | board 즉시 완료 + days 보류 및 역순, 각 오류, lounge 첫 응답 보류, attendance 월 경쟁, boot stale와 valid warm 구분, 상세 실패 시 stack 잔존 여부 |
| 검색 | exerciseSearchSignalsAdapter.test.mjs, exerciseSearchListWindow.test.mjs, 기존 search/mappers 계약 검사 | PC loading prop 실제 소비, 모바일 skeleton 및 오류, catalog와 전체 인덱스 준비 순서, maxAutoPages 미완성 표시. 대량 세션의 입력 반응·완성 대기 실측 |
| 프로필 | profileResource.test.mjs, profilePropsStability.test.mjs, profileDocumentLifecycle.test.mjs, profileDesignIntegration.test.mjs | workspace 미도착 시 body/인입 empty 선공개 여부, field write 이후 늦은 workspace 응답 거부, independent subresource pending/error 경계 |
| 기록/종목 상세 | sessionDetailStore.test.mjs, sessionDetailResource.test.mjs, plannedSessionDetailResource.test.mjs, plannedSessionRevisionContract.test.mjs, sessionDetailPendingRecovery.test.mjs, prExerciseStaleData.browser.mjs, prExerciseDetailResource.test.mjs | planned lite 선공개 방지, completed failure 종료, latest id·revision만 공개, source/store/binding을 통과한 실제 숫자·차트·목록 일괄 공개 |
주 작업에 넘기는 우선 확인 목록
- 모바일에 연결된 홈 PR 준비 신호가 PC에 연결되지 않음.
- PC 검색 loading/initialLoading 전달은 있으나 UI 소비 없음.
- 그룹 라운지 load 상태가 UI에 없고, 그룹 보드 days 준비/오류는 store 공개 타입부터 없음.
- 달력
peek기반 공개와 range 일별 합계 폴백은 ready/invalidated 상태와 분리되어 있음. - 계획 상세는 일부 lite 본문을 먼저 노출할 수 있는 공급 경로가 있음.
- 여러 상세·친구 홈·달력에서 error를 명시 성공/빈/미도착과 다르게 공개하는 연결의 검증이 필요함.
- 위 항목은 확인된 코드 연결 상태이다. 앱 전체가 결함이라는 주장이나 사용자 환경의 재현 증거가 아니며, 구현 뒤에는 전수 대상표 각 행의 실제 검증 상태를 기록해야 전체 완료로 판단할 수 있다.
집계와 독립 구현 가능 파일군
Phase 1 공개 계약 대상은 26개 행(일부 공용 경로는 각 플랫폼/진입 의미를 대조하려고 겹쳐 기재), 모바일 등록 kind는 19개, PC 루트 binding은 8개다. 2026-09-14 Phase 3 대조에서 아래 PC 두 행을 보완하여 현재 공개 계약 대상은 28개 행이다. 행수는 화면 수나 실제 RPC 수를 뜻하지 않는다.
우선 결함 후보는 10묶음으로 집계한다. 전부 런타임 재현 전이며, 1–7은 준비 상태의 실제 공급/소비 누락이 확인됐고 8–10은 오류 공개/종료의 실제 여정을 확인해야 한다.
- PC 홈 PR/연간 필수 준비 신호 누락(H2).
- 달력 무효화/재조회 시 resource validity가 공개 조건에 전달되지 않음(C1/C2).
- 달력 range 준비 전 폴백 합계 공개 및 오류 상태 누락(C3).
- PC 검색 loading/initialLoading 미소비(Q2).
- 그룹 라운지 준비 상태 UI 미전달(G2).
- 그룹 board 완료자/종목 기록의 days 준비·오류 신호 미노출(G3/G4).
- 계획 상세 lite 사본 선공개와 pending 미소비(S2).
- 친구 홈 필수 조회 오류가 홈 성공/빈 표현으로 이어지는 경로(F2).
- 친구 달력 오류가 빈 달력/0합계로 이어지는 경로(F3).
- 완료·친구·그룹 상세 실패 후 source-null skeleton과 navigation stack 종료 일치 여부(S1/F6/G5).
독립 구현은 공통 readiness API가 확정된 후 다음 파일군으로 나눌 수 있다. 각 묶음은 자체 store→binding→UI→관련 검사로 닫히며 루트의 리포트/common readiness 소유 파일은 건드리지 않는다.
| 묶음 | 소유 파일군 | 독립성/주의 |
|---|---|---|
| A. 그룹 공개 | features/group/groupStore.ts, MobileGroupBinding.tsx, groupFeatureContext.ts, ui/mobile/screens/GroupScreen.tsx, 관련 group 검사 | G1–G5 전담 가능. board/day/readiness·라운지·출석·종목 기록까지 한 묶음. 네비게이션 agent의 groupComposer 입력/stack 수정과 충돌 여부만 착수 전 합의 |
| B. 달력 공개 | controllers/calendarReadModelStore.ts, calendarReadModelController.ts, features/calendar/*Binding, useCalendarJournalSelection.ts, ui/mobile/screens/SessionScreen.tsx, DaySummary.tsx/공용 day body, PC calendar/detail parts, 관련 calendar 검사 | C1–C3 전담 가능. 날짜·범위별 validity/error 전달. sessionDetailStore 수정은 입력/상세 담당 소유로 분리하고 PC detail file을 동시에 수정하지 않게 합의 |
| C. 피드·친구 공개 | features/social/feedResource.ts, friendScopeStore.ts, MobileFeedBinding.tsx, MobileFriendScopeBinding.tsx, MobileFriendSessionBinding.tsx, FeedScreen.tsx, 관련 feed/friend 검사 | F1–F6 전담 가능. 친구 리포트는 루트 readiness prop만 연결하고 리포트 내부 수정 금지. PC 홈 피드 UI 변경은 D 소유와 합의 |
| D. 홈·검색·프로필 공개 | features/home/*Binding, features/search/*Binding, features/profile/*Binding/Projection, 해당 M/PC UI 및 관련 검사 | H/P/Q 묶음은 그룹·달력과 독립. 통계 원천 readiness는 루트에서 공급받아 연결. remoteDataController의 검색 로더는 root 공유 파일이므로 수정 필요 시 최소 patch 인터페이스 협의 |
동시에 전부 확장하기보다 현재 가능한 병렬 슬롯에는 A 또는 B처럼 명확히 닫힌 묶음을 배정하는 것이 적합하다. S1/S2는 이미 입력/상세 열기 담당 조사와 직접 겹치므로 그 담당자가 public error/pending 계약까지 수행하고, R1은 루트의 PR 통계 공통 준비 계약과 함께 수행하는 편이 안전하다.
Phase 3 누락 보완 — 공개행 27·28
2026-09-14, /root/coverage_map. Phase 1 원표가 PC 루트에 logtable과 favgroups를 열거했지만 독립 공개행으로 대조하지 않은 누락을 보완했다. 두 행은 기존 앱 범위이며 새 기능 제안이 아니다. 아래는 Phase 3 공유 작업 트리의 공급→binding→UI 소스 대조다. 실제 브라우저나 Production 재현을 완료했다는 뜻이 아니며, 확인된 연결 잔여를 기존 동작 검사 통과로 덮지 않는다.
| ID·플랫폼·영역 | 필수 입력과 실제 공개 경로 | 최종 공개 묶음/캐시 유효성 | 현재 근거·연결 또는 검증 잔여 |
|---|---|---|---|
| D1 (27) PC 로그표·셀/날짜/종목 서랍 | controllers/logTableStore → features/log-table/DesktopLogTableBinding → DesktopLogTableScreen. 월 행은 owner/revision/cache generation/month/exerciseIds 요청 키. 셀 상세는 date+exerciseId와 owner/generation. 별도 PR 요약과 선택 detail을 종목 서랍에 투영 | 월 aggregate 숫자는 현재 월·선택 종목 집합의 응답 준비 후 공개. 셀의 세트/후기는 해당 full cell detail 준비 후 공개. 날짜 서랍은 포함 세션/세트가 모두 준비되어야 하고, 종목 서랍은 R1의 전체 fragment 준비 조건을 따라야 함. 월/셀 LRU 18/64와 owner/late-response 경계 보존 | store의 월 loading은 있으나 월 오류 상태가 없고, binding은 셀 loading/error를 읽지 않음. UI는 월 전체에 기존 overlay, 날짜 및 셀 모달에 loading={false}/error={null} 고정. 날짜 본문은 월 aggregate에서 합친 dayGroups, 종목 상세는 PR 요약 폴백을 사용. 셀 API가 완료/오류 상태를 발행해도 이를 실제 모달 공개에 연결하지 않은 점을 확인. 월·셀·날짜·종목의 준비/실패/재시도 배선 및 actual store→binding→UI 검증 잔여. logTableStore.test.mjs, logTableMonthCache.test.mjs, 대규모 aggregate/선택셀 계약은 기반이며 이번 목표 전체 합격 근거는 아님 |
| D2 (28) PC 커스텀 운동 그룹·종목 검색 | DesktopFavoriteGroupsProvider가 owner별 localStorage 그룹을 동기로 읽고 resolveDesktopFavoriteGroups로 catalog/defaultMainSetExercises와 결합 → DesktopFavoriteGroupsBinding → DesktopFavGroupsScreen | 저장된 그룹 이름·순서·편집 입력은 로컬 완성값이므로 네트워크와 독립. 카탈로그에 의존하는 종목 이름·목록·검색 결과와 기본 그룹 투영은 현재 catalog 실제 적용 후 공개. 서버 소셜 그룹(G행)과 별도 기능 | localStorage 그룹과 편집 callback은 동기. catalog ready/error prop은 binding/UI에 없고 reorderEnabled만 catalog.length로 판단. 준비 중 selFull은 catalog에 있는 id만 남기며 기본 그룹도 catalog/onboarding 도착에 따라 변함. 유효 로컬 그룹·입력은 보존하면서 catalog 의존 영역의 pending/error/retry를 분리할 필요가 있음. localStorage owner/default UUID 정규화 검사는 desktopFavoriteGroups.test.mjs 기반, 실제 catalog hold→완성/오류 UI 검증 잔여 |
이 보완으로 입력 32군과 공개 28행, 총 60개의 대조 행을 유지한다. 겹치는 진입/영역을 포함하므로 ‘60개 화면’이나 ‘60개 테스트’로 집계하지 않는다. Phase 3 대응/검증 결과는 작업 기록에 따로 남기며 미적용·미검증 행이 있으면 전체 완료로 판단하지 않는다.
D2 후속 구현·로컬 검증 — 2026-09-14
CatalogFeature에 실제 카탈로그 공개 상태를 연결하고 PC 그룹 binding이 그 상태와 실제 catalog retry를 소비하도록 수리했다. 그룹 이름·선택·추가·검색 입력은 즉시 사용할 수 있으며, catalog에 의존하는 종목 목록·검색 결과만 pending/error/ready 경계를 사용한다. 미완성 catalog를 기준으로 로컬 그룹을 정규화하면 아직 도착하지 않은 종목 id가 삭제될 수 있으므로, 현재 카탈로그가 ready가 되기 전에는 로컬 편집의 기존 id를 모두 유지한다. 저장 위치·소유자·그룹 편집 의미는 그대로다.
desktopFavoriteGroupsPublication.browser.mjs는 actual exerciseCatalogResource/load adapter → FavoriteGroups provider/binding → 실제 UI를 제어 응답으로 검사해 2/2 통과했다. 기존 desktopFavoriteGroups.test.mjs 12개와 합쳐 14/14다. 준비 중 로컬 이름 수정·그룹 추가·검색/지우기, 로컬 id 보존, 완성 응답 공개, 무효화·오류·force retry, 유효 재방문 추가요청0을 확인했다. 정식 성능·전체 앱 check/precheck·release 반영은 이 증거의 범위가 아니다. D1은 별도 담당자가 수리·검증 중이며 D2 완료를 D1이나 앱 전체 완료로 확장하지 않는다.