기존 E2E 시스템 정비 계획
2026-09-07 · E2E 마스터플랜의 필수 정비 트랙
계획 문서화 기록에 최초 예상 산출물인 기존 39개 + 신규 18개 = 약 57개를 남겼다. 구현 중 main에 S04 CASE-040이 추가되어 현재는 58개 패키지, 자동 PR 집합은 CASE-003을 제외한 57개다. v0.17.2 신규 18개는 CASE-041–058이며, 개발 브랜치의 IndexedDB CASE-040을 CASE-058로 옮겨 main 번호를 보존했다. 아래 원래 처리 계획과 §4.1의 실제 구현 상태를 구분한다. 최종 후보 결과는 구현 기록을 따른다.
새 테스트 추가와 함께 기존 CASE·공통 fixture·실행기·문서·관측·성능 도구를 정비한다. 고장 난 검증은 수리하고, 중복 비용은 줄이며, 필요한 회귀 방어선은 유지한다. 테스트 개수를 줄이는 것 자체를 목표로 삼지 않는다.
1. 확인 범위와 판정 수준
정적 확인 기준은 main 07c04f371b19c300524f2a404ababd26b3962609다. 기존 작업 체크아웃을 바꾸지 않고 해당 커밋의 감사용 사본에서 다음을 대조했다.
- CASE-001–039의 manifest·목적·실행 프로필과 관련 spec/공통 코드.
- Node DB 여정 3종, 실제 mirror/IndexedDB 검사, viewport 계열 3파일, 수동 profile 도구 3파일.
- Playwright 설정 3종, error-case discovery/registry, fixture·오류/장애/cleanup 정책, CI scope·로컬 실행기·원격 workflow, 영문/한국어 운영 문서.
- 기존 상세 감사와 이후 추가된 CASE-039·persistence CI 연결. 이 문서는 최신 전체 E2E 실행 결과나 모든 단언의 동등성 증명은 아니다.
이 정비 계획의 확인 시점에는 manifest가 39개였다. 아래 39행은 기존 CASE 처리 계획의 누락을 막는 목록이며 39개가 모두 새로 실행돼 통과했다는 뜻은 아니다. 현재 구현은 신규 18개와 main의 S04 추가 1개를 포함한 58개이며, 이전 감사의 38개나 이 장부의 39개를 현재 전체 목록으로 사용하지 않는다.
판정은 세 수준으로 구분한다.
- 확인: 소스·manifest·배선에서 직접 확인한 사실. 오류 감시기의 지연 텍스트 누락은 이전 격리 재현도 있다.
- 후보: 실제 통합·삭제·계층 이동 전 같은 요구사항을 대체할 수 있는지 검증해야 하는 항목.
- 유지: 중요한 계약/경계가 달라 현재 근거만으로 합치거나 없애면 안 되는 항목.
현재 근거로 번호 CASE 전체를 무조건 삭제할 대상으로 확정한 것은 없다. 불필요한 비용을 줄일 구체적인 후보는 중복 준비·관측 코드, 옮길 수 있는 API 조합, 오래된 skip과 반복 메타데이터다.
2. 처리 원칙
| 처리 | 선택 조건 | 완료 증거 |
|---|---|---|
| 유지 | 고유한 사용자 경로·계약·사고 재현을 보호 | 요구사항·실행 레인·최근 증거 연결 |
| 수리 | 실패를 놓치거나 정상 결과를 잘못 판정 | 결함을 잡는 대조 시험과 수정 후 결과 |
| 보완 | 현재 단언은 유효하지만 중요한 경계가 비어 있음 | 빈 경계를 명시한 UI/데이터/복구 증거 |
| 공통화 | 준비·관측·기술 동작이 반복되고 의미가 같음 | 기존 CASE별 단언·실패 위치·식별성이 유지됨 |
| 통합 | 같은 시작 상태·행위·관측·오류 경계를 다른 검증이 완전히 포함 | 대체 CASE/하위 테스트와 동등성·실행 비용 비교 |
| 계층/레인 이동 | UI와 무관한 조합 또는 고비용 호환/부하 검증 | 옮긴 검사가 필요한 변경/릴리스 때 반드시 실행됨 |
| 퇴역 | 기능/지원 버전이 실제로 종료되거나 대체 증거가 완성됨 | 삭제 사유·대체 요구사항·과거 증거·구 ID 링크 보존 |
기존 감사 manifest에 등재된 테스트의 수정·삭제는 같은 PR의 tests/audit/pending-changes.json에 신고한다. 기능 PR에서 감사 manifest를 직접 고쳐 통과시키지 않는다. CASE ID는 재사용하거나 일괄 재번호 매기지 않는다. 이는 저장소 테스트 감사 규칙과 기존 CASE 운영 계약에 맞춘다.
3. 번호 CASE 39개 처리 장부
‘주 처리’는 우선 실행할 정비다. 공통화 행도 기존 시나리오가 사라진다는 뜻은 아니다. 실제 삭제/통합 승인에는 §7의 대체 증거가 필요하다.
| CASE | 주 처리 | 유지해야 하는 고유 의미 | 정비 내용 |
|---|---|---|---|
| CASE-001 | 유지 | 횟수 전용 커스텀 종목 생성→입력→저장 렌더 회귀 | CASE-031/038과 종목 준비 도구만 공유. 기록 유형의 의미 보존 |
| CASE-002 | 유지 | desktop 기존 세션 이름 저장의 잠김·데이터 훼손 방지 | mobile 수정 사례로 대체하지 않음. 저장 후 바로 다음 조작 가능한지 시간 기준 연결 |
| CASE-003 | 보완 | 공급자 성공 가정 아래 실제 앱/Supabase 세션 왕복 | 이름·리포트에 provider 가정 명시. 실제 provider 취소/실패/native 복귀는 별도 여정 |
| CASE-004 | 유지 | 저장 직후 피드·일별 상세·집계의 같은 값 | 기준 날짜를 고정하고 해당 날짜로 이동. 저장 성공만으로 대체하지 않음 |
| CASE-005 | 유지 | 성공/실패/미시작 세트의 PR 반영 차이 | 결과 상태 fixture 공통화, 세트별 포함/제외 단언 유지 |
| CASE-006 | 보완 | 페이지 한도를 넘는 PR 성장 데이터·그래프 | 빈 계정 PR와 역할 분리. 과거 날짜 fixture와 기간 이동 고정 |
| CASE-007 | 유지 | Auth 관리자 삭제 cascade와 타 owner 불변 | CASE-017과 대조 사용자/삭제 후 조회 도구 공유. 진입점과 API/storage 범위는 구분 |
| CASE-008 | 보완 | 연간 운동 날짜 집합·운동일 수의 일치 | 고정 업무 날짜·윤년/연도 경계, 현재 연도 의존 제거 |
| CASE-009 | 보완 | 실제 온보딩 입력과 새 세션에서 재온보딩 없음 | 검증/저장 실패 후 입력 유지와 재시도 여정 추가 |
| CASE-010 | 유지 | 이전 lazy chunk 소실 시 제한된 자동 복구 | CASE-039의 outbox 공존과 구분. 번들 준비/버전 식별만 공유 |
| CASE-011 | 수리 | 새 빈 기록 폐기와 구형 제목-only 초안 제거 | 첫 폐기 실패를 두 번째 폐기로 가리는 분기 제거. 두 시작 상태의 결과를 별도로 단언 |
| CASE-012 | 공통화 | 부팅 중 인증 조회 장애에서 기존 runtime/owner 유지 | 013/014와 강등 기록·snapshot·connectivity 관측 helper 공유. 시나리오는 독립 |
| CASE-013 | 공통화 | 실제 TOKEN_REFRESHED 뒤 JWT storm 보존 | 공통 관측만 추출. 토큰 갱신·401 순서·동일 owner 단언 유지 |
| CASE-014 | 공통화 | 기존 앱 문서/연결 리더가 없는 cold start | 공통 관측만 추출. 012의 warm 경로에 흡수하지 않음 |
| CASE-015 | 보완 | 생성의 반복 503→같은 mutation→정확히 한 번 저장 | 실패 주입/queue 관측 공통화. commit 후 응답 유실과 pending 재시작은 별도 요구사항 |
| CASE-016 | 유지 | desktop 새 계획의 저장와 홈 재진입 | 025/034와 계획 준비 도구 공유. desktop 작성 자체를 건너뛰지 않음 |
| CASE-017 | 보완 | 계정 삭제 API와 개인 storage 정리·타인 보존 | 007과 공통 cleanup 검사. 실제 사용자 UI·부분 실패/재시도 경계는 보완 |
| CASE-018 | 보완 | 신고·차단·양방향 관계·관리자 처리·금칙어 | 사용자 신고/차단과 관리자 직접 API/댓글 제약을 요구사항별 분리. 필요 시 독립 테스트화, 준비 데이터 공유 범위 제한 |
| CASE-019 | 유지 | 보드 % 원본과 시작한 사람의 1RM 환산 | 보드 공통 조작 도구만 공유. %/kg와 두 owner 의미 유지 |
| CASE-020 | 유지 | 보드 복합 구조와 parts별 라이브 프리필 | 022의 라이브 직접 입력과 서로 대체하지 않음 |
| CASE-021 | 유지 | 복합 세트 명시 무게 입력·실패 되돌리기 | 유효성 조합 일부는 하위 테스트로 보강하되 rendered 잠금/해제는 유지 |
| CASE-022 | 유지 | 이종 복합의 동작별 기록 필드 | 단일 반복수 또는 동일 기록형 복합으로 대체하지 않음 |
| CASE-023 | 공통화 | 완료 화면→연속 수정의 receipt/revision/자식 ID | 024와 편집·원본 조회 helper 공유. follow-up 저장 연쇄는 유지 |
| CASE-024 | 공통화 | 기존 상세에서 세트/시간/메모만 수정 | 023과 공통 단언 helper 공유. 진입점별 payload와 ID 보존은 독립 검증 |
| CASE-025 | 공통화 | 계획 전체 완료·프리필·후속 메모 수정 | 034와 계획 생성/조회 도구 공유. 전체 완료 결과를 유지 |
| CASE-026 | 공통화 | 보드 시작 후 완료·후속 수정과 출처 보존 | 027/035와 보드/멤버 준비 공유. 완료 기록의 출처·revision은 독립 |
| CASE-027 | 공통화 | 같은 보드 행 수정·재저장·다시 열기 | 보드 CRUD helper 공유. 완료 운동 수정으로 대체하지 않음 |
| CASE-028 | 유지 | 완료 후 한 세트 더 추가해 라이브 재저장 | 줄 ID가 새로 발급될 수 있는 고유 계약 유지. 023의 ID 불변 단언을 그대로 적용하지 않음 |
| CASE-029 | 보완 | offline 수정·삭제의 immediate UI와 queue flush | 생성 015와 장애 도구만 통합. 수정/삭제 각 상태 증거를 분리하고 실제 단절·재시작 추가 |
| CASE-030 | 유지 | 보조 중량의 체중 기반 계산과 사용자 표시 | 031과 데이터 도구 공유 가능. 원본/유효 무게/통계 무게의 다른 의미 유지 |
| CASE-031 | 유지 | 커스텀 종목 무게 배수와 기록 당시 snapshot | 커스텀 생성 UI는 유지. 001/030과 단순 값 교체로 합치지 않음 |
| CASE-032 | 유지 | 완료 화면 삭제의 즉시 닫힘·불필요한 상세 재조회 없음 | 029의 상세 삭제와 같은 CASE로 축소하지 않음. 공통 queue/삭제 조회 활용 |
| CASE-033 | 유지 | 복합 세트 증감 시 부모 세트 수와 parts 수 차이 | DB 그래프 조회 도구 공유. 단순 저장 022와 집계 경계 구분 |
| CASE-034 | 공통화 | 계획 부분 완료가 같은 행으로 전환·미완료 세트 정리 | 025와 데이터 준비만 공유. planned→completed identity·삭제·홈 집계 유지 |
| CASE-035 | 보완 | 멤버가 시작한 완료 기록의 계보와 원 보드 유지 | 그룹 준비 공통화. 현재 RPC fixture의 초대 수락을 실제 초대 UI 증거로 세지 않음 |
| CASE-036 | 계층 분리 | 최신 v5 정상 쓰기와 구 RPC LG426 거부 | 구 API 8종 조합은 DB/API 검증으로 재배치 후보. 브라우저의 업데이트 필요 안내·입력 보존을 별도로 연결한 뒤 중복 실행 제거 |
| CASE-037 | 유지 | catalog 없이 첫 그리기부터 종목 이름 표시 | 038의 변경분 동기화와 구분. UUID 순간 노출의 관측 범위 점검 |
| CASE-038 | 보완 | catalog delta·타 owner 비노출·reload 시 재요청 없음 | 마지막 상태뿐 아니라 대기 관찰 범위가 타당한지 확인. 절대 기다림 대신 필요한 응답/저장 상태 사용 |
| CASE-039 | 보완 | 실제 구형/신형 bundle이 같은 pending 행을 만지는 공존 | 이미 추가된 RPC drain·미러 검증 활용. 구형 bundle 출처/캐시 식별 강화와 지원 버전 matrix 연결 |
4. 공통 시스템의 수리·정리 목록
| ID | 대상·확인한 사실 | 처리와 완료 조건 |
|---|---|---|
| SYS-01 | 오류 감시기의 지연 Text 변경 누락이 남아 있음 | 우선 수리. 빈 alert→문구, 기존 Text 수정, 중첩 변경, 노출 후 제거를 검출. 정상 안내/숨김 요소의 기대 판정도 대조 시험으로 고정 |
| SYS-02 | 오류 표면은 selector+text로 중복 제거됨 | “오류 0” 검사 용도는 유지. 횟수/순서 계약에는 timestamp·occurrence 증거를 따로 제공. 동일 문구 1회/여러 회를 현재 배열 길이로 구분하지 않음 |
| SYS-03 | CASE-011이 첫 폐기 뒤 resume이 보이면 한 번 더 폐기 | 최초 사용자 동작 결과를 먼저 단언. 새 빈 기록과 legacy 초안 시나리오를 분리해 실패 출처 표시 |
| SYS-04 | 012/013/014에 auth downgrade/connectivity 관측 함수 반복 | 목적별 작은 helper로 추출. CASE 전용 전역 이름을 옵션/독립 scope로 바꾸고, owner·발생 순서 증거 보존 |
| SYS-05 | 공통 fixture가 사용자 준비·원본 조회·관측·cleanup·완료 판정을 조립 | 기능 경계별 모듈화 후보. 현재 진입 API와 엄격한 완료 계약 유지. 모든 것을 하는 만능 page object나 불필요한 새 프레임워크는 만들지 않음 |
| SYS-06 | viewport 3파일에 networkidle 실패 무시와 고정 sleep 사용 | 데이터 준비/화면 전환은 명시적 상태로 대기. 애니메이션 검사는 정착한 기하나 종료 신호로 측정. 모든 sleep을 기계적으로 삭제하지 않음 |
| SYS-07 | fixture는 Seoul 오늘, 일부 Node/viewport는 UTC ISO·로컬 Date 혼용 | 업무 기준 날짜와 기간 이동을 고정하고 시간대를 통일. 로그 시각·유일 ID용 Date.now는 무조건 제거하지 않음. 인증 서버 시계는 별도 취급 |
| SYS-08 | 번호 fixture의 cleanup readback은 엄격하나 일부 Node/profile의 deleteUser·정리는 오류를 삼킴 | 공통 cleanup 결과 수집/실패 보고, owner별 추적. 원래 제품 실패를 정리 실패가 덮지 않게 둘 다 기록. 격리 데이터 준비 비용만 줄이고 계정 공유는 하지 않음 |
| SYS-09 | 일반/viewport config가 preview 기동·locale·timezone·retry 설정을 반복 | 작은 공통 설정 builder 도입 후보. testMatch·격리 조건·report 경로·provider 개인정보 제한은 프로젝트별 명시 |
| SYS-10 | runtime source/API 단독 변경이 full 조건에 포함되지 않음 | 마스터플랜의 변경→요구사항 매핑과 필수 집계 추가. selector/환경 누락을 별도 실패로 판정 |
| SYS-11 | local-auth-admin을 준비하지 못하면 discovery에서 제외; viewport는 환경에 따른 skip 가능 | 기대 집합과 실제 수집 집합을 비교. local/credential/staging/provider 결과에 대상·미대상·누락을 표시. 모든 환경이 같은 개수를 검사한다고 보고하지 않음 |
| SYS-12 | profile·환경 계약이 registry/fixture/config/docs에 분산 | 실행 capability·허용 환경 규격을 일치시킨다. 기존 production verification 요구를 없애려면 대상별 계약 이관을 명시하고 검증해 조용히 약화하지 않음 |
| SYS-13 | CASE 문구/체크포인트가 manifest·README·USER-JOURNEY·spec에 반복 | 기계 필드의 정본/생성 영역을 정하고 문서 표 생성. 사고 맥락·실제 사용자 단계·Red/Green 링크는 수기로 보존. 형식 변경과 registry 이관은 같은 PR |
| SYS-14 | registry는 일부 소스의 exact 문자열/형식을 검사 | 실제 발견·manifest schema·완료 증거/누락·행동 검증으로 옮길 후보. 문서와 체크포인트 연결 자체는 보존하며 파일 이름/소스 모양만 맞춘 통과를 줄임 |
| SYS-15 | CASE-039용 legacy bundle은 현재 node_modules로 재빌드하고 tag 폴더의 파일 존재로 cache ready 판단 | 배포 당시 artifact와 재빌드 artifact를 구분. tag가 가리키는 commit·lock/toolchain/build 설정·산출물 hash로 cache 검증. build 성공만으로 당시 운영 bundle과 동일하다고 주장하지 않음 |
| SYS-16 | local CI/원격 workflow에 단계 목록이 따로 있고 현재 대조 테스트가 있음 | 대조 장치는 유지. 실행 레인·필수 결과 inventory를 공통 규격으로 옮길 때 runtime 정책을 검사하는 테스트로 보강 |
| SYS-17 | viewport·Node·provider·독립 browser 검사에 서로 다른 결과 형식 | 공통 결과 인덱스에 SHA·환경·요구사항·첫 시도·cleanup·artifact 위치를 수집. provider의 trace/screenshot 제한은 그대로 지키고 정제된 구조 결과 사용 |
| SYS-18 | browser 4샤드 중 마지막 샤드에 persistence 검사 추가 | 실측 duration·준비 비용·CASE-039 부하를 포함해 균형 조정. 마지막 샤드가 병목이라는 결론은 측정 전 단정하지 않음 |
| SYS-19 | docs의 실행 프로필 안내가 현재 local-auth-admin/fault-injection 분류를 충분히 설명하지 않음 | 영문 정본과 한국어 번역, 명령/선택 범위/로컬·staging·운영 의미를 함께 갱신 |
근거: 오류 감시기, CASE-011, auth 관측 helper, 완료 판정 fixture, scope 정책, 발견 규칙, registry, legacy bundle 도구, 현재 CI 연결.
4.1 v0.17.2 구현 상태
이 표의 ‘구현’은 코드가 연결된 상태다. 최종 SHA의 전체 green/성능/실기기 완료를 뜻하지 않는다. 기존 CASE의 고유 단언과 ID는 유지하며, 수정한 감사 대상은 tests/audit/pending-changes.json에 이유를 남긴다.
| ID | 구현 상태 | 실제 변경·증거 또는 유지 이유 |
|---|---|---|
| SYS-01 | 구현 | userFacingErrorMonitor.mjs의 Text/중첩/제거 관측을 보강하고 실제 browser 대조 검사를 persistence 레인에 연결. 최종 후보 결과 별도 |
| SYS-02 | 구현 | 표면의 발생 증거와 checkpoint 이후 정확한 selector/text/count를 분리. expectedRecovery와 telemetry의 순서/횟수/수신 영수증을 닫힌 manifest로 검증 |
| SYS-03 | 구현 | CASE-011의 두 번째 폐기 우회 제거. 첫 사용자 폐기 결과를 그대로 실패/성공 판정하며 기존 두 시작 상태 유지 |
| SYS-04 | 구현 | 012/013/014의 auth downgrade/connectivity 관측을 authRecoveryObservations.mjs로 공통화. CASE별 scope·owner·실제 순서 유지 |
| SYS-05 | 부분/전면 분해 미구현 | durable/feature/readiness 등 목적별 작은 helper 추가. 기존 fixture 전체를 새 프레임워크로 분해하지 않음. 완료 API와 cleanup 책임을 보존하는 것이 우선 |
| SYS-06 | 구현 범위 제한 | viewport 3파일에서 실패를 삼키는 readiness를 명시적 화면·정착 기하 관측으로 보강. 모든 애니메이션 대기를 기계적으로 삭제하거나 모든 실기기 기하를 검증한 것은 아님 |
| SYS-07 | 부분 구현 | businessDate.mjs로 Node/viewport의 Seoul 업무 날짜·날짜 이동 공유. 실제 JWT 만료·sending TTL·진단 시각은 실제 서버/브라우저 시계 사용. 전 CASE 날짜 조합 전수화는 미완료 |
| SYS-08 | 부분 구현 | Node DB/빈 계정·viewport의 cleanup 실패 수집과 owner 삭제/readback을 강화. 기존 번호 fixture의 엄격한 정리 유지. 수동 profile 도구 전부의 정리 규격 전환은 미구현 |
| SYS-09 | builder 미구현/설정 유지 | 각 config의 testMatch·격리·provider 개인정보·report 차이를 명시적으로 보존. required 환경/시간대/실패 정책만 맞춤. 설정 중복 제거만을 위한 별도 공장 추상화는 추가하지 않음 |
| SYS-10 | 구현 | 실행 코드/미분류 경로는 full. Markdown 등 닫힌 예외만 verify-only. verify가 DB/browser/viewport/evidence까지 기다리도록 연결 |
| SYS-11 | 구현 | required local profile의 준비 실패는 즉시 오류. 사전 57 CASE/14 viewport inventory와 실제 동일 SHA/run/샤드 완료를 대조. skip·0건·중복·누락·flaky 거절 |
| SYS-12 | 구현 범위 제한 | local-only fault profile와 실제 만료 JWT signer·expected recovery 계약을 registry/fixture/CI에 연결. 생산 환경 provider 조건을 자동 로컬 통과로 대체하지 않음 |
| SYS-13 | 생성 체계 미구현 | manifest/README/USER-JOURNEY/spec의 기존 연결 검사 유지. 신규 패키지의 단계와 의미를 동기화했으나 저장소 전용 메타데이터 생성 규격·전 사례 이관은 하지 않음 |
| SYS-14 | 부분 구현/소스 검사 유지 | runtime 완주/evidence와 누락/예상 오류 행동 검증을 추가. 기존 exact source/문서 연결 검사를 AST 등으로 대체하는 이관은 미구현; 감시 단언을 줄이지 않음 |
| SYS-15 | 구현 | legacy cache를 tag commit·입력/lock/toolchain/build 설정·artifact hash로 검증. source-rebuild로 출처를 표시하며 당시 운영 artifact와 동일하다고 주장하지 않음 |
| SYS-16 | 구현 범위 제한 | 로컬/원격 scope와 required evidence 정책을 맞추고 기존 대조 테스트 강화. 모든 실행기를 하나의 추상화로 교체하지 않음 |
| SYS-17 | 부분 구현 | browser/viewport는 SHA/run/첫 시도/완주/cleanup 구조 결과와 집계 연결. Node/provider/native/performance/restore 전체의 만능 결과 인덱스는 미구현; 별도 증거 유지 |
| SYS-18 | 기존 구성 유지/재균형 미구현 | 독립 DB의 4샤드와 마지막 샤드 persistence 유지. 최종 통합 57개 자동 집합의 단일 성공 run은 8분 55초, 가장 느린 shard 3/4의 DB 준비 2분 25초·여정 5분 6초. 실측은 구현 기록 §8에 보존했으며 p95 비교·재균형·비용 절감은 미완료 |
| SYS-19 | 문서 갱신 | 이 마스터플랜·구현 기록과 영문/한국어 browser 운영 문서를 같은 PR에서 동기화. 최종 원격 CI·보호 설정·staging 결과와 별도 출시 증거를 구현 기록 §8에 구분 |
036의 구 RPC 8개 조합은 이번에 삭제하거나 이동하지 않았다. 실제 LG426 browser 안내·보존 단계를 추가하여 API 조합만으로 UI를 보장하던 공백을 먼저 메웠다. 전면 퇴역한 번호 CASE는 0개다. 미구현 후보를 신규 여정 수에 합산하거나 SYS 19개 전체 완료로 보고하지 않는다.
5. 번호 밖 스위트·도구 처리
| 대상 | 판정 | 구체적인 정비 |
|---|---|---|
e2e/crudRoundtrip.e2e.mjs | 유지·부분 정리 | 실제 DB 계약과 배포 smoke 역할 유지. note 상세 영구 skip은 현재 활성 note 단언과 범위를 대조해 복구 또는 중복 블록 퇴역 |
e2e/emptyAccountJourney.e2e.mjs | 유지·수리 | 정말 한 번도 쓰지 않은 계정 경계 유지. PR records 0건 영구 skip을 현재 DB에서 확인하고 동작 수리 또는 검증 복구. populated CASE-006으로 대체하지 않음 |
e2e/cardioMinOneField.e2e.mjs | 유지·공통화 | 실제 RPC가 유산소 최소 필드를 받는지 유지. 세 Node 여정의 provisioning·기준 날짜·cleanup 결과 도구 공유 |
tests/react/pendingSaveMirror.browser.mjs | 유지 | 실제 IDB/mirror 원문 보존을 앱/DB 없이 빠르게 검사하는 독립 browser integration. CASE-039 및 앱 재시작 full-stack을 대체하지 않음 |
e2e/viewport-matrix.spec.mjs | 유지·수리 | viewport/tier별 폭·배경·댓글 시트 검사 유지. 공통 navigation/seed·상태 대기·오류 증거 보강 |
e2e/dock-geometry.spec.mjs | 유지·공통화 | dock/tabbar/brand 행의 기하 계약 유지. matrix와 setup·측정 primitive 공유 |
e2e/bottom-clearance.spec.mjs | 유지·공통화 | 16 surface의 하단 도달·safe-area 조건 유지. 파일이 길다는 이유로 다른 기하 검사에 흡수하지 않음 |
e2e/profile/tabSwitch.profile.mjs | 측정 의미 대조 후 정리 | React commit/탭 전환 비용의 관측 정의를 확인. paint profile이 포함하는 지표만 실제로 겹치면 합침 |
e2e/profile/tabSwitchPaint.profile.mjs | 유지·G04 연결 | 사용자가 보는 paint/첫 반응 측정은 G04의 서버 시간과 다름. 공통 fixture·측정 결과 schema·기기/CPU/빌드 식별 연결 |
e2e/profile/renderGranularity.profile.mjs | 유지·G04 연결 | 렌더 범위 진단은 필요 시 수동 진단으로 유지. 자동 release gate인지 별도 표기하고 full-stack 통과 수에서 제외 |
scripts/performance/measure/browser.mjs | 유지·재사용 | 초기 cold/warm 비용 러너를 정본으로 활용. 위 profile의 고유 지표는 보존하고 준비·증거 조립의 중복부터 통합 |
| 세 Playwright config | 공통 기반·경계 유지 | 공통 기동/시간대만 공유. browser·viewport·provider의 testMatch, 데이터 권한, 기록 제한, 결과 경로는 명시적 유지 |
scripts/ci-local.mjs와 원격 workflow | 단계/증거 동기화 | shared inventory + 필요한 실행 능력 확인. persistence의 browser:false는 현재 preview 기동 분류이므로 “브라우저를 안 쓴다”로 해석하지 않도록 이름/모델 정리 |
smoke:prod 등 npm 별칭 | 의미 유지 | 같은 하위 명령을 호출해도 운영 목적의 진입 이름은 유용. 실행 환경/허용 범위 확인을 공통화하고 이름 중복만으로 삭제하지 않음 |
| CASE 패키지 4파일과 영문/한국어 안내 | 정본·생성 영역 분리 | 반복 메타데이터는 생성, 사람에게 필요한 사고 맥락/여정은 유지. 번역 정합성·명령 최신화 |
근거: note 상세 skip, 빈 계정 PR skip, 독립 IDB/mirror 검사, viewport 대기, 로컬 단계 분류.
6. 합칠 것과 분리해서 남길 것
| 묶음 | 합칠 대상 | 분리해 남길 검증 |
|---|---|---|
| 인증 012/013/014 | snapshot checkpoint·강등 관측·connectivity timeline | boot outage / token-refresh storm / cold start |
| 수정 023/024/026 | 편집 조작·receipt/ID/revision readback 도구 | 완료 화면 follow-up / 기존 상세 / 보드 출처 |
| 계획 016/025/034 | 계획 데이터 builder·조회·카드 관측 | desktop 작성 / 전체 완료 / 부분 완료·같은 행 전환 |
| 보드 019/020/026/027/035 | 그룹/멤버 준비·board locator·스냅샷 조회 | % 환산 / 복합 parts / 후속 수정 / 보드 재저장 / 타 멤버 계보 |
| 저장 장애 015/029/032/039 | 요청별 fault injector·queue/receipt 관측·cleanup | 생성/수정/삭제의 정책, 완료 화면 즉시 닫힘, 실제 구/신 탭 |
| 삭제 007/017 | 대조 사용자와 잔존 그래프·storage 검증 도구 | Auth cascade / 사용자 계정 삭제 API·storage 정리 |
| viewport 3파일 | 인증·seed·navigation·rect 측정·artifact 형식 | tier/overflow / dock geometry / 마지막 콘텐츠 하단 도달 |
| profile 3파일/G04 | workload/계정 생성·시간 표본·결과 schema·정리 | React commit / paint / 렌더 범위 / cold 초기 비용 |
시나리오 변형을 parameterized test로 만들더라도 각 변형이 독립된 이름·결과·요구사항·실패 trace를 가진다. 한 테스트 안의 긴 loop로 바꿔 첫 실패가 나머지 검증을 모두 가리게 하지 않는다.
테스트 fixture를 공유할 때는 순수 builder/기술 도구를 공유한다. 테스트 간 mutable DB 계정·browser storage·clock·진행 중 queue를 공유해 준비 시간을 줄이지 않는다. 같은 shard 안에서도 데이터와 cleanup 소유권은 분리한다.
7. 없어도 되는 부분의 퇴역 조건
삭제 또는 축소 후보는 다음과 같이 제한한다.
| 후보 | 제거할 수 있는 조건 | 남길 것 |
|---|---|---|
| note 상세의 오래된 skip 블록 | 현재 활성 검사 또는 복구한 검사로 동일 note decode·UI/DB 경계가 실제 확인됨 | 원래 사고 링크, 대체 검사 위치 |
| 빈 계정 PR의 오래된 skip 사유 | 현재 결함 여부를 확인하고 해당 0건 경계를 활성 검사로 회복 | 0건 시나리오 자체 |
| CASE-036의 반복 구 RPC API 조합 | 하위 DB/API 계약 검사와 필수 CI 연결로 8종 거부·무변경을 모두 증명 | 최신 앱 v5 왕복, 브라우저에서의 실제 거절 UX, 구 API 호환 방어선 |
| 테스트별 복제 helper | 동작·fault scope·관측 범위가 같은 공통 helper가 검증됨 | 각 CASE의 사용자 경로·독립 기대값·사고 checkpoint |
| 의미 없는 고정 대기 | 필요한 앱/DB/애니메이션 상태를 직접 관찰 가능 | 제한 시간·실제 상태 전이·측정 목적상 필요한 관찰 구간 |
| 동등한 기하/성능 반복 측정 | 시작 환경·surface·측정 정의·경계값이 같고 한 검증이 다른 검증을 포함 | 고유 플랫폼/기하/paint/상호작용 경계 |
| 반복 메타데이터 수기 입력 | 정본에서 재생성·검증할 수 있고 기존 링크/증거 보존 | 사용자 여정과 사고의 맥락, 체크포인트 추적 |
| 소스 문구만 맞추는 검사 | 실제 발견/산출물/행동 검사가 같은 위반을 잡음 | 의도된 경계·우회 방지·필수 실행 보장 |
| 구형 bundle·지원 버전 fixture | 해당 버전의 지원/공존 의무 종료가 명시되고 잔여 구 client 정책과 일치 | 유지하는 최소 구형 버전·현재 후보의 호환 검사, 과거 결과 |
퇴역/통합 PR은 다음을 함께 제출한다.
- 제거 전후
요구사항 → CASE/하위 테스트 → 필수 레인매핑. 필수 요구사항 누락 0. - 같은 앱 후보·데이터 조건의 전후 결과. 테스트 구성이 바뀌었으면 양쪽 test revision도 명시.
- 사고 회귀는 보관된 Red 증거를 연결하고, 가능하면 동일 원인 입력/결함 fixture에 대해 대체 검증도 실패함을 확인. 매번 옛 제품 전체를 새로 빌드하는 의식적 절차로 만들지는 않음.
- wall time·runner minutes·setup/cleanup·최장 shard·artifact 비용의 변화. 아직 측정하지 않았으면 개선 수치를 주장하지 않음.
- 감사 신고, 문서/manifest/discovery/결과 소비자의 이관, 이전 CASE ID에서 대체 검증으로 가는 링크.
대체 증거가 없으면 기존 검증을 유지한다. 처음부터 신·구 전체를 영구 이중 실행하지 않고, 이관 PR에서 동등성을 확인한 뒤 중복 실행을 제거한다.
8. 실행 순서와 작업 단위
마스터플랜의 M0–M7에 아래 정비 작업을 끼워 넣는다. 기능 전체를 추가한 뒤 마지막에 청소하는 일정으로 미루지 않는다.
| 단계 | 작업 묶음 | 선행/완료 기준 |
|---|---|---|
| 정리-1 · M0 | 39 CASE와 번호 밖 스위트 inventory, 요구사항/레인/시간 분포 기준 | 최신 main을 고정하고 이미 해결된 내용 제외. 기존 G02/G05와 연결 |
| 정리-2 · M1 우선 | 오류 감시기·CASE-011·skip·필수 실행/증거 누락 수리 | 거짓 성공부터 차단. 새 행동 테스트와 기존 회귀 결과 확보 |
| 정리-3 · M1/M2 | auth/편집/계획/보드 helper, 공통 config·cleanup·날짜·기하 대기 | 작은 경계별 PR. 시나리오·사용자 계약·격리 유지 |
| 정리-4 · M2/M3 | CASE-018 요구사항 분리·CASE-036 계층 분리, fault/queue 관측 공통화 | 새 핵심/복구 여정을 같은 도구로 추가. 오래된 API/UI 증거의 차이 해소 |
| 정리-5 · M0/M1 및 관련 PR | registry·manifest·문서·결과 인덱스 이관 | 기계 정본/생성 영역·지원 환경·누락 판정 정합. 형식 작업만으로 제품 검증 완료 표시 금지 |
| 정리-6 · M5 | profile/G04 연결·legacy bundle provenance·viewport/실기기 레인 | 고유 지표와 호환 경계 보존. 새 artifact 식별 검증 |
| 정리-7 · M6 전 | 대체 완료 항목 퇴역·샤드 균형/중복 준비 최적화·전체 검증 | 필수 요구사항/환경 누락 0, stale skip 미해결 0, 기존 사고 증거 연결, 시간/비용 전후 비교 |
정리-5의 규격/결과 설계는 정리-1에서 결정하고, 소비자 코드는 해당 기능 PR과 함께 이관한다. 공용 fixture 전면 교체와 모든 CASE 이동을 한 PR에 묶지 않는다. 기존 v0.18.0 작업의 선행/담당 경계를 유지한다.
9. 이 트랙의 완료 기준
- 현재 CASE와 번호 밖 모든 실행/진단 스위트가 유지·수리·보완·공통화·이동·퇴역 중 하나의 처리 결과와 담당을 가진다.
- “삭제해도 된다”는 항목은 대체 요구사항·증거가 실제 연결돼 있고, “아직 확인 필요”는 완료로 합산하지 않는다.
- 핵심 예상치 못한 오류를 검출하며, 예상 오류·취소·timeout은 좁은 범위의 제품/시험 계약으로 구분한다.
- CASE ID·원래 사고·Red/Green 기록·사용자 여정의 의미를 추적할 수 있다.
- 선택된 검사가 미수집/미실행/환경 부족/cleanup 실패여도 초록으로 보이는 경로가 없다.
- 테스트 준비·실행·정리·증거 생성 비용과 가장 느린 shard를 보고하고, 통합 전후 필수 범위가 줄지 않았음을 확인한다.
- G05 기능 장부와 마스터플랜의 정상·복구·성능·플랫폼·배포 기준이 연결돼 있다.
원래 처리 계획과 실제 구현 결과는 §4.1에서 구분한다. 머지·배포·최종 후보 일괄 통과 여부는 별도 구현 기록의 릴리스 증거가 채워져야 확정한다.