핵심 UI 업무 종료 경계 대조 — v0.17.2

2026-09-08 · 기준 main 32835b0c541f195dc137250ea6117da81d5be049 · 읽기 전용 소스 감사. 이 문서는 새 실행 결과나 제품 결함 재현 보고가 아니다. 번호 CASE 58개 중 PR 필수 57개의 실제 spec과 관련 하위 검사를 대조했다. CASE003은 PR 필수 집합 밖이다.

사용자 기준은 “자주 쓰는 UI에서 예상치 못한 오류 때문에 저장·진행을 못 하는 상황을 E2E가 막아야 한다”이다. 아래에서 종료는 버튼 클릭·화면 표시만이 아니라 해당 업무의 실제 결과, DB 값/정체성, 재진입 후 같은 결과까지 뜻한다. 실패 이후 자동 재전송, 같은 화면의 사용자 재시도, 새로고침 후 재진입은 서로 구분했다. 공용 오류 감시기 자체의 누락 여부는 별도 검토 범위다.

핵심 흐름	정상 실제 UI → 업무 종료 → DB → 재진입 근거	실패 → 보존 → 실제 재시도 → 종료 근거	진행 차단 우려의 구체적 공백·최소 보완
1. 첫 로그인·기존 로그인 재진입	인증 이후 첫 사용: [CASE009 L35][c009-35]에서 실제 온보딩 입력·제출·환영·홈, [L87][c009-87]에서 프로필·신체·1RM·동의 DB, [L170][c009-170]에서 새 인증/페이지·reload 후 홈. `openAuthenticatedApp`으로 시작하므로 최초 provider 가입 UI를 완주한 증거는 아니다. 기존 사용자: [CASE003 L29][c003-29]은 desktop 로그인 버튼·Supabase 신원·reload이나 provider 성공 가정이며 PR 필수가 아니다.	[CASE049 L59][c049-59]는 실제 로그인 버튼 → 취소 → 활성 버튼 유지 → 코드 교환 400 → 다시 버튼 → 홈 → 실제 Auth/DB 신원 → reload를 검사한다. 단, [L25][c049-25]에서 authorize/PKCE 응답을 제어하고 성공 응답에 준비된 실제 세션을 사용한다. [CASE012 L84][c012-84]/[CASE014 L87][c014-87]는 이미 저장된 owner snapshot의 bootstrap 503 후 자동 복구·동일 owner 재진입을 검사한다.	온보딩 마지막 제출이 실패했을 때 입력·동의·중복제출 제어를 유지하고 같은 버튼으로 완료하는 경계가 없다. CASE009 L63–68은 성공 응답만 기대한다. CASE009에 실패 1회 후 동일 입력 재시도→홈·기존 DB/reload를 잇는 보완이 적합하다. 실제 provider 가입/동의 완료는 이 자동 집합의 주장 범위 밖에 명시해야 한다.
2. 운동 시작·초안 이어하기·폐기	시작해서 저장하는 정상 흐름은 [CASE004 L57][c004-57]과 CASE001에 있다. 초안 관련 CASE011은 [L25][c011-25]의 빈 운동 종료·초안 없음, [L45][c011-45]의 직접 주입한 제목만 있는 옛 초안 → 이어하기 → X → reload 후 ghost 없음, [L80][c011-80]의 DB 신규 쓰기 없음이다.	[CASE058 L22][c058-22]는 완료 시 pending enqueue 실패 뒤 현재 입력/operationId 보존, [L61][c058-61]에서 현재 완료 화면 저장 버튼 재시도→DB 1행·빈 대기열·reload. [CASE042 L9][c042-9]/CASE048은 이미 완료 저장을 요청해 pending 상태가 된 기록의 재기동이며, 입력 중인 active draft 복원은 아니다.	우선 보완 ①: 실제 종목·세트를 입력한 미완료 초안을 페이지 재진입 뒤 ‘이어서 하기’로 복원하고 끝까지 저장하는 E2E가 없다. 현재 CASE011의 초안은 종목 0개이며 직접 IDB 주입이다. 같은 CASE011 안에서 실제 입력→기기 보존→새 페이지/restore UI→원문 값 유지→추가 입력 가능→완료 저장·DB 1행→reload를 잇는다. 비어 있지 않은 초안의 삭제 확인→재진입 시 복원되지 않음도 기존 빈 초안 폐기와 구별되는 미검증 경계다.
3. 종목 검색/추가·세트 입력·완료 저장	[CASE001 L33][c001-33] 실제 커스텀 종목 생성/추가·횟수 입력→[L85][c001-85] 완료·원본 DB/상세→[L177][c001-177] reload. 일반 무게×횟수는 [CASE004 L57][c004-57]→[L84][c004-84]에 있다. desktop 실제 picker 검색·선택·복수 세트는 [CASE016 L144][c016-144]. 추가 기록 타입/복합 세트는 CASE021/022/030/031 등 별도 정상 여정이 존재한다.	완료 저장 실패는 [CASE015 L106][c015-106]의 503 두 번→동일 pending 원문→자동 전송·DB 1행·reload, [CASE058 L22][c058-22]의 실제 IDB abort→입력 보존→화면 저장 버튼 재시도, [CASE046 L24][c046-24]의 영구 거부→보관된 원문→[L57][c046-57] 실제 복구 버튼→새 정체성의 DB 1행·reload까지 있다.	저장 종료 자체는 대표 실패에서 강하게 검증된다. 다만 운동 picker의 첫 카탈로그 로딩 실패 뒤 검색/선택을 회복해 그 운동을 완료하는 경계는 없다. [CASE037 L108][c037-108]은 응답 지연 중 홈 즐겨찾기 이름 검사이고, [CASE054 L19][c054-19]의 IME는 내 종목 관리 검색과 보관 실패 복구다. 이 둘을 운동 picker의 실패 복구 증거로 세면 안 된다. 필요 보완은 CASE037에서 실패/복구 후 실제 picker 선택→한 세트 저장을 잇는 작은 경계이며, 검색 조합 전수 추가는 요구하지 않는다.
4. 완료 기록 수정·삭제	[CASE024 L133][c024-133] 실제 세트 수정, [L160][c024-160] 시간/메모 수정→같은 canonical 행·개정번호→[L222][c024-222] reload 값. desktop [CASE002 L60][c002-60]은 completed 기록 이름 수정→편집기 해제·일지 재조작·동일 자식행·reload. [CASE032 L158][c032-158]은 완료 화면 삭제 확인→응답 전 UI 닫힘→[L191][c032-191] 실제 삭제·자식행 0→[L218][c032-218] reload 부재.	[CASE029 L280][c029-280] 수정 503→편집기 종료·기기 원문/서버 이전 값→[L361][c029-361] 자동 재전송·같은 자식행, [L402][c029-402] 삭제 503→즉시 UI 제거·pending→[L477][c029-477] 실제 삭제·reload. [CASE041 L64][c041-64]은 commit 뒤 ACK 유실의 생성/수정/삭제 멱등 결과, [CASE045 L93][c045-93]·[L131][c045-131]은 실제 충돌/늦은 ACK 뒤 현재 편집·삭제 의도 수렴을 검사한다.	이 대표 사용 흐름에서 우선순위가 높은 새로운 종료 공백을 이번 대조로 확인하지 못했다. 기존 정상·outbox 자동 복구·현재 UI 수렴 단언을 유지한다. 자동 전송으로 복구하는 계약을 불필요한 ‘재시도 버튼’ 신설 요구로 바꾸지 않는다.
5. 계획 생성/수정/운동 전환	[CASE016 L130][c016-130] desktop 계획 추가→실제 검색·복수 세트/자유 기록→[L186][c016-186] 저장·편집기 해제·홈/일지 조작→[L220][c016-220] reload·계획 상세·DB 값. mobile [CASE025 L135][c025-135] 생성→[L191][c025-191] 계획 카드에서 운동 시작·세트 프리필·완료·메모→[L255][c025-255] 같은 계획 ID가 completed로 전이→[L273][c025-273] reload. [CASE034 L197][c034-197]는 두 계획 세트 중 한 세트만 완료한 같은 행 전이를 추가 검증한다.	기존 planned 행을 실제 상세의 수정 버튼으로 열어 변경 저장하는 정상 여정부터 없다. 따라서 planned 저장 실패 뒤 입력 원문 보존·기기 보관 안내·실제 복구 전송·저장 종료 E2E도 없다. CASE002의 `workout.plan.saveBar` 표식은 계획 수정 증거가 아니다. [CASE002 L23][c002-23]이 `createCompletedSession`으로 준비한 완료 기록을 수정한다. CASE016 cleanup의 `R.deletePlannedSession`도 사용자 UI 삭제가 아니다.	우선 보완 ②: CASE016은 standard/Production 범위를 유지하며 기존 reload→계획 상세 뒤 실제 계획 수정→동일 planned ID/개정번호/자식 값·reload를 추가한다. 실패는 기존 fault-injection CASE029에서 계획 수정 503→기기 보관·편집기 종료→실제 연결 복구·재전송→서버/재진입으로 검증한다. A13 현재 코드 L515는 retryable 편집 실패를 save_plan으로 큐잉하고 L587에서 기기 보관 안내 후 성공처럼 편집기를 닫는 계약이다. 같은 편집기 유지나 별도 재시도 버튼을 강제하지 않는다. CASE016의 기존 생성·홈 잠김·세 종목/자유 기록 단언과 cleanup, CASE029의 기존 완료 기록 수정/삭제 단언을 보존한다.
6. 홈·달력·상세·PR/통계 조회	[CASE004 L130][c004-130] 저장 직후 소유자 피드와 달력의 세트/횟수/볼륨→[L169][c004-169] DB/RPC·reload 일치. [CASE005 L75][c005-75]는 시작/실패 세트의 실제 원본/RPC와 PR 상세, [CASE006 L124][c006-124]는 페이지를 모두 읽은 PR 성장 그래프→[L144][c006-144] reload. [CASE008 L86][c008-86]은 DB 날짜 집합→실제 리포트 ready·연간 운동일/잔디→[L150][c008-150] reload.	Home bootstrap outage는 CASE012/014에 있다. 상세는 [CASE047 L43][c047-43]의 지연 응답 선택 보호, [L66][c047-66]의 상세 503·로그인 강등 없음→재진입 후 실제 값이다. 주의: L86의 `reloadRecord`는 [helper L144][reload-144]에서 page.reload부터 수행하므로, 오류 직후 같은 세션에서 항목을 다시 눌러 복구되는 것을 검증하지는 않는다.	달력/PR/통계의 독립 조회 실패 뒤 현재 앱에서 다시 진행하는 경계는 미검증이다. manifest의 bootstrap 장애는 `get_profile_workspace`, 상세 장애는 `get_session_detail`에 한정된다. Home 보존만으로 실패한 다른 탭의 재시도 UI 작동을 대신할 수 없다. 가장 작은 보완은 CASE047에서 오류 후 reload 전에 실제 기록 항목 재선택→값 확인을 추가하고, 이후 기존 reload도 유지하는 것. PR/리포트는 대표 한 조회 실패→현재 제공 UI의 재진입/재시도→실제 데이터 ready 경계를 그 여정을 소유한 CASE006/008에 추가하는 후보로 남긴다.

하위 검사와 실제 E2E의 경계

초안의 복원/TTL/로그아웃 보존은 [workoutDraftLifecycleScenarios L105][draft-105]에 행동 검사가 있다. 그러나 [L12][draft-12]의 test server와 memory store, [L61][draft-61]의 화면 callback 대체를 사용하는 store/lifecycle 검사다. 실제 입력 화면·restore 버튼·완료 버튼 배선과 Supabase 최종 저장까지 통과한 증거가 아니다. [workoutDraftRestorePrompt L118][draft-prompt-118]의 정적 렌더/배선 검사도 의미가 있지만 그 경계를 대신하지 못한다.
계획 수정은 [planRoundTripHarness L225][plan-harness-225]가 서버 상세 형태→command→planned payload의 ID/revision을 검사한다. [L123][plan-harness-123]에서 RPC 응답을 성공 receipt로 대체하며 실제 browser/DB 왕복은 없다. 계획 UI 저장 실패 후 편집기를 다시 조작하는 것을 증명하지 않는다.
온보딩은 [onboardingCommands L28][onboard-unit-28]의 command/동의 검사가 있으나, CASE009의 완료 제출 실패 뒤 실제 폼 보존·재시도 흐름을 대신하지 않는다.
별도 Chromium의 React authResume·outbox persistence 검사도 실제 브라우저 저장소/컨트롤러 경합을 검증하는 유효한 하위 검사다. 전체 앱의 업무 종료 경계로 합산하지 않는다. 반대로 이 감사는 해당 검사를 “없음”으로 판정하지 않는다.

보완 순서와 완료 기준

현재 실제 정상 종료 자체가 비어 있는 입력한 초안 이어하기와 기존 계획 수정을 각각 CASE011/016 안에서 먼저 완성하고 계획 장애 복구는 기존 CASE029에 잇는다. 번호 증가나 같은 CASE의 별도 test 중복 없이 기존 저니에 검증 단계를 추가한다.
초기 감사에서 찾은 나머지 실패 경계는 온보딩 제출, 운동 picker 초기 읽기, 조회 오류 뒤 reload 없는 재진행이다. 이는 미재현 제품 버그 목록이 아니며, 현재 통과 결과로 넓은 UX 보장을 주장할 수 없는 정확한 경계다. 공통 감시기 보완과 같은 목적의 중복 감사를 추가하지 않는다.
추가한 단계는 실제 사용자 입력/클릭, 실패 시 DB 불변, 보존된 입력, 제품 계약이 정한 실제 UI 동작과 재시도/자동 전송, 성공 후 정체성/값과 재진입을 함께 요구한다. 기존 7개 완료 신호가 CASE 전체에 있다는 이유만으로 새 단계의 DB/재진입을 생략하지 않는다. 이번 문서 작업은 읽기 대조만 수행했고 DB·browser·원격·repo 변경은 하지 않았다.

추가 보강 추적

위 표는 #1361이 머지된 시점의 공백을 보존한 감사다. #1383·PR #1386에서 CASE011 실제 입력 초안의 이어하기/완료, CASE016 기존 계획의 정상 편집, CASE029 계획 편집의 기기 보관/실제 복구 전송, CASE047 새로고침 전 상세 다시 열기를 보강했다. CASE029가 검출한 자동 재전송 부재와 저장 후 열린 상세의 옛 값 잔류도 수정했다. CASE028·045의 실행 순서 보완 및 최종 검증·staging 결과는 구현 기록 §10에 별도로 기록한다. 나머지 독립 장애 경계는 미검증으로 유지하며 이 네 보강을 전체 장애 조합의 완성으로 합산하지 않는다.

핵심 UI 업무 종료 경계 대조 — v0.17.2 ​

하위 검사와 실제 E2E의 경계 ​

보완 순서와 완료 기준 ​

추가 보강 추적 ​

핵심 UI 업무 종료 경계 대조 — v0.17.2

하위 검사와 실제 E2E의 경계

보완 순서와 완료 기준

추가 보강 추적