#1478 테스트 품질 감사 — v0.17.9

현재 필수 범위: 2026-09-10 사용자 결정으로 와드업·관리자 CASE를 제외한 75 CASE를 적용한다. 아래 79건 판정은 제외 전 이력이며 CASE-056의 U를 유지한다.

79건 중 78건 적합, 1건 미검증. 79 × 15 = 1,185개 조건 중 P 1,184 / F 0 / U 1이다. 유일한 U는 관리자 CASE-056의 기준14이며, 읽기 전용 자격과 실제 hosted CI 실행 증거가 없어 품질 승인을 보류한다.

앱 PR #1497과 문서·관리자 PR #8의 변경 후보를 검증했다. 최초 요청대로 v0.17.7 Production 커밋에서 분기했고, 작업 중 v0.17.8 배포 후 오너 승인으로 v0.17.9로 이동했다. 앱 PR1497은2026-09-10 05:12:53 KST에v0.17.9 release의19e97f215c9c77d46a6eb6be511158579ddf3a2c로통합됐다. Production배포와관리자hosted검증은미완료다.

필수 품질 기준15개 · 최초 감사와 당시 실패 · 전체 판정·인용값·원본 해시 JSON

확인한 후보와 실행

구분	실제 근거
앱 코드	93d4cad61d09d2c0c546145dd6dc73d8eab82721
관리자 코드	37aa8f0cdc452e36346323eb0bce7ce3d1c77c83 (후속 문서만의 커밋과 구분)
앱·화면 부분 실행	local-1788983964771-26036, 앱56+viewport22=78/78, 재시도·skip·flaky0, 필수 증거 집계 통과,6분6초
사전 검증	local-1788983833096-85404, 최신 release 10d4df67 반영·정적/단위/빌드·격리DB 통과,7분52초
단위·공통 도구	앱 check3,505pass/0fail/33조건부 DBskip. 실제 Chromium23/23. 관리자 check155/155 및 local build
실제 DB	pgTAP130파일/2,328단언, deadline SQL취소2개, 동시CRUD·통계수렴 통과. 조건부 skip을 실제 DB 실행으로 별도 보완
대표 SQL 결함	앱5+관리자2=7실험의 정상→원래 목표 실패→복원 정상21단계. 소유자038/044,멱등041,권한053/056,원자성055/056
관리자	CASE056의 필수2시나리오가 두 SQL실험의3단계마다 실행되어12개 native결과. 정리/SQL해시/소유권/권한 원복 확인. hosted미검증

실행 통과와 품질 적합을 분리했다. 정적 입력 P576/U609에서 기준별 명시 검토609개를 실제 CASE의 checkpoint·상황·같은 reader의 결함 탐지·복원·정리·예산·진단에 연결했다. 생성기는 SHA·파일 해시·정확한 인용값을 검증하고 마지막에 원본 해시를 다시 확인했다. 생성기 회귀9/9도 통과했다.

CASE별 경계 control은 DOM/CSS 또는 실제 HTTP 응답을 바꾼 관측 검사다. 실제 서버 구현 결함은 위7개의 SQL실험이며, 검사하지 않은 DB 제약이나 외부 제공자 로그인 전체로 범위를 확대하지 않는다. 과거 문서의 미완료 요청은 기록에 남기고 실제 문서/탭 종료와 요청 성공 종료를 구분한다. 원래 실패와 이후 수동 수리 검증은 다른 실행으로 보존했다.

79건 전체 판정표

CASE	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	승인
CASE-001	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-002	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-004	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-005	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-006	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-007	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-008	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-009	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-010	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-011	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-012	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-013	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-014	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-015	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-016	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-017	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-018	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-019	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-020	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-021	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-022	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-023	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-024	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-025	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-026	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-027	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-028	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-029	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-030	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-031	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-032	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-033	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-034	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-035	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-036	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-037	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-038	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-039	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-040	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-041	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-042	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-043	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-044	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-045	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-046	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-047	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-048	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-049	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-050	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-051	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-052	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-053	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-054	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-055	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-056	P	P	P	P	P	P	P	P	P	P	P	P	P	U	P	U
CASE-057	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
CASE-058	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
V0 compact 320x568	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
V1 phone 360x780	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
V2 phone 375x667	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
V3 phone 390x844	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
V5 phone 440x956	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
V6 wide-touch 820x1180	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
V7 wide-touch 984x1092	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
V8 wide-touch 932x440	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
P1 pointer-mockup 800x900	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
D1 desktop 1440x900	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
D3 desktop 1280x720	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
comment sheet: input row never overlaps the tabbar band	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
workout dock states + tabbar + brand row geometry	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
16 surfaces: content never ends under the bottom chrome (safe 0/34)	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
그룹장 이름 저장·공지 두 개 작성은 새로고침 뒤 라운지와 지난 공지에 유지된다	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
워드마크에서 초대를 수락하고 실제 팔로우 알림 읽음은 새로고침 뒤 유지된다	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
댓글 알림은 첫 피드 페이지 밖 내 운동 한 개를 실제 조회하고 올바른 댓글 시트를 연다	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
아이언맨·기능성 트레이너 선택을 저장하고 새로고침 뒤 현재 카드·홈 직업명이 유지된다	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
성별 해제·키·체중을 한 요청으로 저장하며 pending 중에는 서버 값과 입력을 보존한다	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
연간·월간 이동은 선택한 기간만 읽고 실제 10칸 분포 네 종류를 표시한다	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
먼저 요청한 8월 응답이 늦게 도착해도 새로 선택한 연간 리포트를 덮어쓰지 않는다	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P
상세 RPC 일시 실패는 로그인 상태를 유지하며 재시도로 실서버 데이터를 복구한다	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P	P

CASE별 판정 근거

각 행의 실제 관측 ID·값·원본 artifact 해시와 모든 소스 참조는 위 JSON의 cases[].checks 및 observations에서 확인한다. 공유 도구의 증거는 각 CASE 고유 조건·정답 증거와 함께 연결하며 다른 CASE의 실행 결과로 대체하지 않는다. 아래는 현재 판정과 주요 소스 참조이고, 최초 감사는 원래 SHA와 판정을 보존한다.

<a id="case-1"></a> <details><summary>CASE-001 — Mobile custom exercise reps render crash (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 사용자는 빈 운동 세션에서 횟수 전용 커스텀 종목 "high clean and jerk"를 만들고 3회를 입력한 뒤 운동을 저장하고, 새로고침 후 동일한 기록을 오류 없이 다시 열 수 있다. 실제정상경로는브라우저·인증API/직접DB단언에연결되고추가control은dom 경계로선언된다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. 고정과거연도나이전CASE데이터를필수전제로쓰지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: 아래구간에서응답·표시상태·DB revision/저장행을단언후다음행동을한다. 공통요청drain은관측중요청의종료만검사하며목표UI/DB준비를대신하지않는다. 소스1 소스2
5. 독립적인 정답	P	정적: 요구 입력 reps=3, recording_fields=[reps], load=null과 종목/세션 owner를 UI·draft·직접 DB·상세 RPC에서 비교한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Mobile custom exercise reps render crash: 실제 완료한 필수 상황·목표 checkpoint는 custom-reps-state, exact-persistence, reload-reentry, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 횟수 전용 사용자 종목의 편집 화면이 중량 입력 없이 3회 입력을 정상 표시해야 한다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적: 중량 필드 없음, camelCase draft, fatal shell 없음, 단일 종목/세트, 저장·reload 상세의 3회를 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	custom-reps-state, exact-persistence, reload-reentry, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 횟수 전용 사용자 종목의 편집 화면이 중량 입력 없이 3회 입력을 정상 표시해야 한다. 실제 DOM에 대응하는 대표 control 'case-001-reps-only-render-loss'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 3개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 8654ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적: 기본expect/action/navigation은각10초이고이spec의명시적대기상향은10초이하이며test timeout60초를상속한다. 같은조건의자동CASE재실행으로대기상한을늘리지않는다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-2"></a> <details><summary>CASE-002 — Desktop session rename save deadlock (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 사용자는 기존 완료 세션의 이름을 변경해 저장한 뒤 즉시 운동일지를 계속 사용할 수 있고, 새로고침 후에도 운동·중량·횟수 데이터가 훼손되지 않은 동일 세션을 다시 열 수 있다. 실제정상경로는브라우저·인증API/직접DB단언에연결되고추가control은dom 경계로선언된다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. 고정과거연도나이전CASE데이터를필수전제로쓰지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: 아래구간에서응답·표시상태·DB revision/저장행을단언후다음행동을한다. 공통요청drain은관측중요청의종료만검사하며목표UI/DB준비를대신하지않는다. 소스1 소스2
5. 독립적인 정답	P	정적: 입력 제목 및 70kg×5, revision 1→2를 상수로 판정하고 수정 전 직접 읽은 canonical child 필드를 수정 후와 전부 비교한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Desktop session rename save deadlock: 실제 완료한 필수 상황·목표 checkpoint는 save-and-interaction, aggregate-and-reentry, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: rename 저장이 revision2에 도달하면 편집기와 scrim이 사라져 일지 상호작용이 가능해야 한다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적: 편집기와 scrim 제거, 일지 재조작, 같은 session id, 제목/개정/갱신시각 외 필드와 child 불변, reload를 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	save-and-interaction, aggregate-and-reentry, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: rename 저장이 revision2에 도달하면 편집기와 scrim이 사라져 일지 상호작용이 가능해야 한다. 실제 DOM에 대응하는 대표 control 'case-002-rename-editor-remains-blocking'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 3개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 5402ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적: 기본expect/action/navigation은각10초이고이spec의명시적대기상향은10초이하이며test timeout60초를상속한다. 같은조건의자동CASE재실행으로대기상한을늘리지않는다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-3"></a> <details><summary>CASE-004 — Mobile post-save owner feed and day summary (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 사용자는 모바일에서 70kg × 5회 세트를 완료해 세션을 저장한 직후와 새로고침 후 모두 피드에서 본인 세션 포스트를 확인하고, 캘린더의 오늘 날짜 상세에서도 저장한 세션 제목과 운동·세트 행 및 기존 당일 기록 기준 350kg·1세트·5랩 증가분을 확인할 수 있다. 실제정상경로는브라우저·인증API/직접DB단언에연결되고추가control은dom 경계로선언된다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. 고정과거연도나이전CASE데이터를필수전제로쓰지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: 아래구간에서응답·표시상태·DB revision/저장행을단언후다음행동을한다. 공통요청drain은관측중요청의종료만검사하며목표UI/DB준비를대신하지않는다. 소스1 소스2
5. 독립적인 정답	P	정적: 기존 완료 원본의 독립 집계에 새 70×5의 350kg·1세트·5랩 증가분을 더해 UI/day RPC를 판정한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Mobile post-save owner feed and day summary: 실제 완료한 필수 상황·목표 checkpoint는 exact-save-and-home-return, immediate-owner-feed-hydration, immediate-home-day-hydration, feed-and-calendar-reload-reentry, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 저장 직후 오늘 요약이 원본 baseline 대비 350kg·1세트·5랩 증가해야 한다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적: 즉시 본인 feed와 day 상세·제목·종목·세트 및 reload 후 합계를 검사한다. 기존 당일 기록을 0으로 가정하지 않는다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	exact-save-and-home-return, immediate-owner-feed-hydration, immediate-home-day-hydration, feed-and-calendar-reload-reentry, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 저장 직후 오늘 요약이 원본 baseline 대비 350kg·1세트·5랩 증가해야 한다. 실제 DOM에 대응하는 대표 control 'case-004-post-save-summary-stays-at-baseline'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 3개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 8375ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적: 기본expect/action/navigation은각10초이고이spec의명시적대기상향은10초이하이며test timeout60초를상속한다. 같은조건의자동CASE재실행으로대기상한을늘리지않는다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-4"></a> <details><summary>CASE-005 — Set outcomes and PR detail round trip (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 사용자는 성공 세트 5회, 0회 실패 세트, 시작하지 않은 세트를 포함한 운동을 저장한 뒤 PR 종목 상세에서 성공·실패 두 세트만 정확히 확인하고, 새로고침 후에도 종목 요약·PR 기록·최근 탑세트·훈련 목록 데이터가 오류 없이 유지되는 것을 확인할 수 있다. 실제정상경로는브라우저·인증API/직접DB단언에연결되고추가control은http-response 경계로선언된다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. 고정과거연도나이전CASE데이터를필수전제로쓰지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: 아래구간에서응답·표시상태·DB revision/저장행을단언후다음행동을한다. 공통요청drain은관측중요청의종료만검사하며목표UI/DB준비를대신하지않는다. 소스1 소스2
5. 독립적인 정답	P	정적: 완료 70kg×5와 실패 75kg×0만 남고 미시작 세트는 없다는 명시적 두 행 배열을 직접 DB/history/UI에서 판정한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Set outcomes and PR detail round trip: 실제 완료한 필수 상황·목표 checkpoint는 persisted-outcomes-and-rpcs, rendered-pr-detail, reload-pr-detail, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 성공70×5와 실패75×0 두 시작 세트가 남고 미시작 세트는 빠져야 한다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적: 성공·0회 실패·미시작의 세 경계, 정확 set id 형식, split RPC 계층, reload history를 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	persisted-outcomes-and-rpcs, rendered-pr-detail, reload-pr-detail, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 성공70×5와 실패75×0 두 시작 세트가 남고 미시작 세트는 빠져야 한다. SDK가 읽는 실제 HTTP 응답1건에 대응하는 대표 control 'case-005-zero-rep-failure-disappears-from-history'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. HTTP 응답 경계의 결함 검출이며 실제 DB 제약을 제거한 제품 결함 실험으로 확대하지 않는다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 4813ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적: 기본expect/action/navigation은각10초이고이spec의명시적대기상향은10초이하이며test timeout60초를상속한다. 같은조건의자동CASE재실행으로대기상한을늘리지않는다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-5"></a> <details><summary>CASE-006 — Desktop PR growth pagination (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 사용자는 PR 기록이 첫 페이지 한도를 넘어도 종목 상세에서 전체 실측 기록 로딩이 끝나고 1RM 성장 그래프가 표시되며, 새로고침 후에도 같은 그래프와 최신 1RM을 오류 없이 확인할 수 있다. 실제정상경로는브라우저·인증API/직접DB단언에연결되고추가control은http-response 경계로선언된다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. 고정과거연도나이전CASE데이터를필수전제로쓰지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: 아래구간에서응답·표시상태·DB revision/저장행을단언후다음행동을한다. 공통요청drain은관측중요청의종료만검사하며목표UI/DB준비를대신하지않는다. 소스1 소스2
5. 독립적인 정답	P	정적: rep target 18개를 두 시점에 만들어 36개 고유 기록, 첫 32개/뒤4개, target당2개 및 명시적 최신 1RM을 기대한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Desktop PR growth pagination: 실제 완료한 필수 상황·목표 checkpoint는 persisted-two-page-records, rendered-growth-chart, reload-growth-chart, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 첫32개와 뒤4개를 합치면 중복 없는36개 실제 기록을 모두 읽어야 한다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적: 페이지 상한 32 초과, cursor 종료, id 중복, 개별 target 횟수, 로딩 완료 후 graph/reload를 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	persisted-two-page-records, rendered-growth-chart, reload-growth-chart, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 첫32개와 뒤4개를 합치면 중복 없는36개 실제 기록을 모두 읽어야 한다. SDK가 읽는 실제 HTTP 응답1건에 대응하는 대표 control 'case-006-pagination-repeats-a-first-page-record'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. HTTP 응답 경계의 결함 검출이며 실제 DB 제약을 제거한 제품 결함 실험으로 확대하지 않는다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 5525ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적: 기본expect/action/navigation은각10초이고이spec의명시적대기상향은10초이하이며test timeout60초를상속한다. 같은조건의자동CASE재실행으로대기상한을늘리지않는다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-6"></a> <details><summary>CASE-007 — Auth user deletion cascades completed workout data without cross-account damage (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 관리자가 완료 운동 데이터가 있는 사용자를 삭제하면 Auth 사용자와 그 사용자의 프로필·운동 그래프·파생 행만 하나의 요청으로 삭제되고, 다른 사용자의 로그인·운동 데이터·렌더링 경험은 그대로 유지되어야 한다. 실제정상경로는브라우저·인증API/직접DB단언에연결되고추가control은http-response 경계로선언된다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. 고정과거연도나이전CASE데이터를필수전제로쓰지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: 아래구간에서응답·표시상태·DB revision/저장행을단언후다음행동을한다. 공통요청drain은관측중요청의종료만검사하며목표UI/DB준비를대신하지않는다. 소스1 소스2
5. 독립적인 정답	P	정적: 삭제 전 대상82×3·대조64×5 및 각각의 owner를 확인하고 삭제 뒤 대상 graph 부재와 대조 aggregate의 완전 동일성을 비교한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Auth user deletion cascades completed workout data without cross-account damage: 실제 완료한 필수 상황·목표 checkpoint는 isolated-predelete-state, auth-delete-cascade, control-render-reentry, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: Auth 사용자 삭제 후 해당 owner의 원본 session과 자식 그래프가 남지 않고 control 사용자 데이터는 유지되어야 한다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적: Auth 대상 부재·대조계정 존재, 원본/파생/직접 child id 잔존0, 대조 profile·로그인·UI·reload 유지. 소스1 소스2
8. 필수 단언과 비동기 완료	P	isolated-predelete-state, auth-delete-cascade, control-render-reentry, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: Auth 사용자 삭제 후 해당 owner의 원본 session과 자식 그래프가 남지 않고 control 사용자 데이터는 유지되어야 한다. SDK가 읽는 실제 HTTP 응답1건에 대응하는 대표 control 'case-007-deleted-owner-leaves-a-session-row'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. HTTP 응답 경계의 결함 검출이며 실제 DB 제약을 제거한 제품 결함 실험으로 확대하지 않는다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 3개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 5734ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적: 기본expect/action/navigation은각10초이고이spec의명시적대기상향은10초이하이며test timeout60초를상속한다. 같은조건의자동CASE재실행으로대기상한을늘리지않는다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-7"></a> <details><summary>CASE-008 — Mobile report workout days and grass round trip (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 사용자는 여러 날짜에 저장된 운동이 있는 연간 리포트에서 실제 운동 날짜와 정확히 같은 날짜의 잔디만 색칠되고, 표시된 운동일 수가 PostgreSQL·인증 RPC·색칠된 잔디 날짜 집합의 동일한 개수와 일치하며, 새로고침 후에도 같은 결과를 오류 없이 확인할 수 있다. 실제정상경로는브라우저·인증API/직접DB단언에연결되고추가control은dom 경계로선언된다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. 고정과거연도나이전CASE데이터를필수전제로쓰지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: 아래구간에서응답·표시상태·DB revision/저장행을단언후다음행동을한다. 공통요청drain은관측중요청의종료만검사하며목표UI/DB준비를대신하지않는다. 소스1 소스2
5. 독립적인 정답	P	정적: 완료 session·part·set 원본으로 연간 날짜 집합/볼륨을 독립 집계한다. stats·report RPC·색칠된 날짜·카운트를 그 집합과 비교한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Mobile report workout days and grass round trip: 실제 완료한 필수 상황·목표 checkpoint는 persisted-annual-date-set, rendered-count-and-grass, reload-count-and-grass, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 0kg 운동일을 포함해 원본 완료 session과 정확히 같은 날짜들만 연간 잔디에서 활성화되어야 한다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적: 복수 날짜, zero-volume 완료일, 윤년 포함 연간 모든 날짜의 중복/순서/개수, 원요청 asOf 및 reload 일치. 소스1 소스2
8. 필수 단언과 비동기 완료	P	persisted-annual-date-set, rendered-count-and-grass, reload-count-and-grass, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 0kg 운동일을 포함해 원본 완료 session과 정확히 같은 날짜들만 연간 잔디에서 활성화되어야 한다. 실제 DOM에 대응하는 대표 control 'case-008-zero-volume-day-not-colored'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 4713ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적: 기본expect/action/navigation은각10초이고이spec의명시적대기상향은10초이하이며test timeout60초를상속한다. 같은조건의자동CASE재실행으로대기상한을늘리지않는다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-8"></a> <details><summary>CASE-009 — Onboarding profile data round trip (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 신규 사용자가 모바일 온보딩에서 입력한 주 운동 스타일, 키, 체중, 골격근량, 체지방률, 초기 1RM이 하나의 완료 요청으로 저장되고 새 인증 세션과 새로고침 뒤에도 온보딩을 반복하지 않아야 한다. 실제정상경로는브라우저·인증API/직접DB단언에연결되고추가control은dom 경계로선언된다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. 고정과거연도나이전CASE데이터를필수전제로쓰지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: 아래구간에서응답·표시상태·DB revision/저장행을단언후다음행동을한다. 공통요청drain은관측중요청의종료만검사하며목표UI/DB준비를대신하지않는다. 소스1 소스2
5. 독립적인 정답	P	정적: UI에 입력한 style/sex/178.4cm/82.4kg/39.7kg/17.3%와 각 초기1RM 상수를 authenticated reads 및 원본 행에 대조한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Onboarding profile data round trip: 실제 완료한 필수 상황·목표 checkpoint는 mobile-onboarding-submit, profile-storage-readback, fresh-auth-reload, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 입력 프로필을 완료 저장한 사용자는 새 인증 세션과 reload 뒤 온보딩을 반복하지 않아야 한다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적: 신규 requiresOnboarding 확인, 완료 요청 성공, 동의/초기PR 기록, 새 인증 context와 reload 뒤 온보딩 재노출0. 소스1 소스2
8. 필수 단언과 비동기 완료	P	mobile-onboarding-submit, profile-storage-readback, fresh-auth-reload, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 입력 프로필을 완료 저장한 사용자는 새 인증 세션과 reload 뒤 온보딩을 반복하지 않아야 한다. 실제 DOM에 대응하는 대표 control 'case-009-completed-onboarding-shown-again'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 3개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 3160ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적: 기본expect/action/navigation은각10초이고이spec의명시적대기상향은10초이하이며test timeout60초를상속한다. 같은조건의자동CASE재실행으로대기상한을늘리지않는다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-9"></a> <details><summary>CASE-010 — Stale lazy chunk auto recovery (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 사용자는 배포 전에 열어둔 모바일 앱에서 피드처럼 아직 열지 않은 화면을 눌러 이전 해시 청크가 사라졌더라도 앱이 자동으로 정확히 한 번만 새로고침되고, 같은 동작을 다시 선택하면 최신 화면이 표시되며 인증 상태와 데이터가 보존되고 무한 새로고침이나 오류 화면이 발생하지 않는다. 실제정상경로는브라우저·인증API/직접DB단언에연결되고추가control은session-storage 경계로선언된다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. 고정과거연도나이전CASE데이터를필수전제로쓰지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: warmup 완료 mark, 실제 문서 요청, 영속 guard 및 중복 preloadError의 defaultPrevented=false를 함께 검사한다. 제품은 guard 존재 시 동기 false를 반환하고 성공할 때만 setTimeout(...,0)으로 reload를 예약한다. 250/500ms는 해당 사건 뒤 추가 요청 부재의 유한 관측창이며 준비 완료 추정이나 무한 시간의 부재 증명이 아니다. 소스1 소스2
5. 독립적인 정답	P	정적: Feed 청크404 정확1회, 자동 top-level reload 정확1회, guard version1, 그다음 feed 표시와 전체 청크요청2회를 명시한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Stale lazy chunk auto recovery: 실제 완료한 필수 상황·목표 checkpoint는 authenticated-state-before-recovery, single-automatic-reload, recovered-feed-route, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 첫 자동 재로드 이후 같은 탭의 재로드 예산을 소비했다는 영속 guard가 남아야 한다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적: warmup 완료 mark, 실제 문서 요청, 영속 guard 및 중복 preloadError의 defaultPrevented=false를 함께 검사한다. 제품은 guard 존재 시 동기 false를 반환하고 성공할 때만 setTimeout(...,0)으로 reload를 예약한다. 250/500ms는 해당 사건 뒤 추가 요청 부재의 유한 관측창이며 준비 완료 추정이나 무한 시간의 부재 증명이 아니다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	authenticated-state-before-recovery, single-automatic-reload, recovered-feed-route, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 첫 자동 재로드 이후 같은 탭의 재로드 예산을 소비했다는 영속 guard가 남아야 한다. 실제 sessionStorage에 대응하는 대표 control 'case-010-single-reload-budget-guard-lost'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 2822ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적: 기본expect/action/navigation은각10초이고이spec의명시적대기상향은10초이하이며test timeout60초를상속한다. 같은조건의자동CASE재실행으로대기상한을늘리지않는다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-10"></a> <details><summary>CASE-011 — Mobile empty drafts discard and an authored workout resumes through completed storage (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 사용자가 내용이 없는 새 모바일 운동 기록을 현재 화면의 종료·삭제 동작으로 버리면 앱은 이를 진행 중인 기록으로 보존하지 않으며, 기존 버전이 남긴 시작 단계 제목뿐인 초안은 기존 시작 화면으로 복원되더라도 X로 닫은 뒤 브라우저 저장소에서 제거되어 새로고침 후 마저 기록 작성하기가 다시 나타나지 않아야 한다. 실제로 종목·무게·횟수·제목을 입력한 운동은 반대로 사용자 소유 IndexedDB 초안에 보존되어야 한다. 페이지를 닫고 같은 브라우저 저장소로 재진입한 뒤 이어하기를 누르면 동일 초안 식별자와 입력을 복원하고, 사용자가 세트·종목·운동을 완료하면 단일 서버 원본으로 저장되어 다시 열어도 같은 값을 보여야 한다. 실제정상경로는브라우저·인증API/직접DB단언에연결되고추가control은indexeddb 경계로선언된다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. 고정과거연도나이전CASE데이터를필수전제로쓰지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: 아래구간에서응답·표시상태·DB revision/저장행을단언후다음행동을한다. 공통요청drain은관측중요청의종료만검사하며목표UI/DB준비를대신하지않는다. 소스1 소스2
5. 독립적인 정답	P	정적: 빈 초안 null/서버 baseline 불변과 직접 입력한 제목·63kg×5·완료전false를 구분한다. 저장 전에 읽은 실제 표시 날짜/id를 재진입 및 서버 값과 비교한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Mobile empty drafts discard and an authored workout resumes through completed storage: 실제 완료한 필수 상황·목표 checkpoint는 untouched-record-discard, legacy-resume-close, no-server-write, authored-draft-persisted, authored-draft-page-reentry, resumed-workout-committed, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: legacy 제목뿐인 초안을 resume 후 닫으면 owner IndexedDB row가 없어야 한다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적: 새 빈 기록 버리기, legacy title-only 삭제, 실제 작성 초안의 page close/resume, identity/입력 보존, 단일 source 서버행 및 queue/draft 비움. 소스1 소스2
8. 필수 단언과 비동기 완료	P	untouched-record-discard, legacy-resume-close, no-server-write, authored-draft-persisted, authored-draft-page-reentry, resumed-workout-committed, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: legacy 제목뿐인 초안을 resume 후 닫으면 owner IndexedDB row가 없어야 한다. 소유 IndexedDB 행에 대응하는 대표 control 'case-011-discarded-title-only-draft-survives'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 3개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 14142ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적: 기본expect/action/navigation은각10초이고이spec의명시적대기상향은10초이하이며test timeout60초를상속한다. 같은조건의자동CASE재실행으로대기상한을늘리지않는다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-11"></a> <details><summary>CASE-012 — Boot auth outage preserves minimized snapshot access (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 저장된 로그인 세션과 최소화된 홈 스냅샷이 있는 기존 사용자는 앱 부팅 중 인증 프로필 요청이 일시적으로 두 번 실패해도 로그인 화면이나 오류 화면으로 강등되지 않고 동일한 사용자 소유권과 degradedReady 열람을 유지한 채 세 번째 재시도로 온라인 홈에 복귀하며, 새 진입에서도 같은 인증 사용자와 데이터 접근을 유지해야 한다. 실제정상경로는브라우저·인증API/직접DB단언에연결되고추가control은indexeddb 경계로선언된다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. 고정과거연도나이전CASE데이터를필수전제로쓰지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: 아래구간에서응답·표시상태·DB revision/저장행을단언후다음행동을한다. 공통요청drain은관측중요청의종료만검사하며목표UI/DB준비를대신하지않는다. 소스1 소스2
5. 독립적인 정답	P	정적: 고정 allowlist/schema/소유자 검증을 통과한 live snapshot을 준비하고 두503 전후 동일성을 비교한다. auth owner·onboarding완료 및 lifecycle 순서를 독립 상수로 기대한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Boot auth outage preserves minimized snapshot access: 실제 완료한 필수 상황·목표 checkpoint는 owner-snapshot-survives-declared-outage, third-attempt-recovers-online-home, fresh-tab-preserves-owner, journey-completion이다. 선언한 실패 bootstrap-profile-workspace-503:POST /rest/v1/rpc/get_profile_workspace의 실제 요청·시도 관측에서 missingAttempts/violations가 모두 비었다. 필수 복구 사건 observedCount=2와 누락/위반0도 확인했다. 목표: 두 bootstrap503 동안 기존 owner의 최소 snapshot이 유지되어야 한다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적: 정확2개503+보류3번째, snapshot삭제 금지, 로그인/오류강등0, gate해제 후 online과 새탭 동일owner. 소스1 소스2
8. 필수 단언과 비동기 완료	P	owner-snapshot-survives-declared-outage, third-attempt-recovers-online-home, fresh-tab-preserves-owner, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 두 bootstrap503 동안 기존 owner의 최소 snapshot이 유지되어야 한다. 소유 IndexedDB 행에 대응하는 대표 control 'case-012-boot-outage-deletes-owner-snapshot'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 5개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 6612ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적 보강 확인: snapshot 읽기와 재조회 간 대기를 하나의 performance.now 마감으로 묶고, 각 작업 후에도 마감을 재확인하며 timeoutMs>10000을 거절한다. 횟수 제한만으로 wall 상한을 주장하던 공백이 코드에서 해소됐다. 실제 CASE 실행의 시간 결과는 #11 및 공통 실행 검증과 별개다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-12"></a> <details><summary>CASE-013 — TOKEN_REFRESHED JWT storm preserves session and minimized snapshot (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 저장 세션을 실제로 TOKEN_REFRESHED 한 직후 profile-workspace가 연속 두 번 JWT 401을 반환해도 기존 사용자 세션과 최소화된 홈 스냅샷은 보존되고, 앱은 첫 401의 세션 재확인과 두 번째 storm 차단을 거쳐 재로그인이나 오류 화면 없이 세 번째 성공으로 온라인 홈에 복귀하며 새 진입에서도 갱신된 동일 사용자 세션을 유지해야 한다. 실제정상경로는브라우저·인증API/직접DB단언에연결되고추가control은indexeddb 경계로선언된다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. 고정과거연도나이전CASE데이터를필수전제로쓰지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: 아래구간에서응답·표시상태·DB revision/저장행을단언후다음행동을한다. 공통요청drain은관측중요청의종료만검사하며목표UI/DB준비를대신하지않는다. 소스1 소스2
5. 독립적인 정답	P	정적: 갱신 성공→JWT401 순서, TOKEN_REFRESHED 있음/SIGNED_OUT 없음, 실제 owner와 미래 expiry, 검증된 live snapshot의 동일성을 기대한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	TOKEN_REFRESHED JWT storm preserves session and minimized snapshot: 실제 완료한 필수 상황·목표 checkpoint는 refreshed-session-survives-jwt-storm, third-attempt-recovers-online-home, fresh-tab-keeps-refreshed-session, journey-completion이다. 선언한 실패 token-refreshed-profile-workspace-401:POST /rest/v1/rpc/get_profile_workspace의 실제 요청·시도 관측에서 missingAttempts/violations가 모두 비었다. 필수 복구 사건 observedCount=3와 누락/위반0도 확인했다. 목표: 실제 TOKEN_REFRESHED와 두 JWT401 뒤에도 최소 snapshot의 사용자 소유권이 유지되어야 한다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적: 토큰갱신 뒤2개JWT401·3번째보류, 소유권/스냅샷 유지, 강등0, 원래 세션으로 새탭 재진입. 소스1 소스2
8. 필수 단언과 비동기 완료	P	refreshed-session-survives-jwt-storm, third-attempt-recovers-online-home, fresh-tab-keeps-refreshed-session, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 실제 TOKEN_REFRESHED와 두 JWT401 뒤에도 최소 snapshot의 사용자 소유권이 유지되어야 한다. 소유 IndexedDB 행에 대응하는 대표 control 'case-013-jwt-storm-snapshot-owner-switch'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 6개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 6690ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적 보강 확인: snapshot 읽기와 재조회 간 대기를 하나의 performance.now 마감으로 묶고, 각 작업 후에도 마감을 재확인하며 timeoutMs>10000을 거절한다. 횟수 제한만으로 wall 상한을 주장하던 공백이 코드에서 해소됐다. 실제 CASE 실행의 시간 결과는 #11 및 공통 실행 검증과 별개다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-13"></a> <details><summary>CASE-014 — Cold start reads the minimized owner snapshot (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 기존 앱 문서와 연결 리더가 모두 사라진 뒤에도 저장 세션과 schemaVersion 3 HOME_MINIMIZED snapshot (IndexedDB database version 2)을 가진 사용자는 새 모바일 앱 문서에서 두 번의 정확한 profile-workspace 503 동안 같은 owner의 degradedReady Home을 읽고, 실제 세 번째 성공 뒤 live Home과 동일 owner 재진입을 회복해야 한다. 현재 명세와 실제 검사 계층을 대조했다. 실행 합격 판정은 별도 U 항목에 남긴다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. 고정과거연도나이전CASE데이터를필수전제로쓰지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	seed 문서를 열기 전 실제 catalog/month/순차 warming 마지막 volume 관측기를 등록하고, 각 완료 1회 이상·pending0·failed0을 단언한 뒤 manifest로 이동한다. Home 노출이나 순간적인 quiet만으로 seed 준비 완료를 판단하지 않는다. cold/reentry의 원래 목표와 단언은 보존했다. 소스1 소스2
5. 독립적인 정답	P	정적: 실제 앱이 만든 schema3 최소 snapshot의 allowlist와 owner를 검증해 seed로 삼고 기존 앱 문서를 제거한 뒤 동일 payload/owner와 online회복을 비교한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Cold start reads the minimized owner snapshot: 실제 완료한 필수 상황·목표 checkpoint는 cold-document-reads-owner-snapshot, third-attempt-recovers-live-owner, later-page-keeps-owner, journey-completion이다. 선언한 실패 cold-start-profile-workspace-503:POST /rest/v1/rpc/get_profile_workspace의 실제 요청·시도 관측에서 missingAttempts/violations가 모두 비었다. 필수 복구 사건 observedCount=2와 누락/위반0도 확인했다. 목표: 기존 문서가 사라진 cold-start 탭에서도 저장된 최소 Home payload를 읽을 수 있어야 한다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적: 기존 document 소멸, 새문서2개503·3번째보류, 실제owner snapshot 유지·로그인강등0, 새탭회복. 소스1 소스2
8. 필수 단언과 비동기 완료	P	cold-document-reads-owner-snapshot, third-attempt-recovers-live-owner, later-page-keeps-owner, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 기존 문서가 사라진 cold-start 탭에서도 저장된 최소 Home payload를 읽을 수 있어야 한다. 소유 IndexedDB 행에 대응하는 대표 control 'case-014-cold-start-home-snapshot-payload-missing'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 8개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 6708ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적 보강 확인: snapshot 읽기와 재조회 간 대기를 하나의 performance.now 마감으로 묶고, 각 작업 후에도 마감을 재확인하며 timeoutMs>10000을 거절한다. 횟수 제한만으로 wall 상한을 주장하던 공백이 코드에서 해소됐다. 실제 CASE 실행의 시간 결과는 #11 및 공통 실행 검증과 별개다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-14"></a> <details><summary>CASE-015 — Degraded create survives a failed recovery flush without duplicates (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 완료 화면 자동 저장의 첫 전송과 첫 recovery flush가 같은 503으로 실패해도 운동 기록은 정확히 한 개의 owner pending row와 동일 mutation identity로 보존되고(완료 화면에는 오류가 아니라 '동기화 후 점수 반영' 안내), 두 번째 복구 뒤 서버에 한 번만 생성된 다음 reload에서도 중복이나 대기 row 없이 보여야 한다. 실제정상경로는브라우저·인증API/직접DB단언에연결되고추가control은indexeddb 경계로선언된다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. recovery clock은 실제 현재 시각에서 설치하고 관측된 backoff만 전진한다. 고정 날짜나 요청 날짜를 대체하지 않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: 아래구간에서응답·표시상태·DB revision/저장행을단언후다음행동을한다. 공통요청drain은관측중요청의종료만검사하며목표UI/DB준비를대신하지않는다. 소스1 소스2
5. 독립적인 정답	P	정적: 실제 UI70×5와 정확owner pending1개를 기대한다. 최초행의 hash/body/identity를 실패재전송과 비교하고 fence/attempt +1, 최종 서버1개를 독립 상수로 검사한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Degraded create survives a failed recovery flush without duplicates: 실제 완료한 필수 상황·목표 checkpoint는 initial-failure-durable-row, failed-flush-retains-row, second-recovery-persists-once, reload-keeps-one-session, journey-completion이다. 선언한 실패 completed-workout-create-and-first-flush-503:POST /rest/v1/rpc/save_session_v5의 실제 요청·시도 관측에서 missingAttempts/violations가 모두 비었다. 필수 복구 사건 observedCount=4와 누락/위반0도 확인했다. 목표: 동일 운동은 초기503과 recovery 재실패 동안 owner pending row 정확히1개로 남아야 한다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적: 최초503·첫복구503·두번째복구성공, pending중복/유실 금지, claim 재획득과만료, 동일body, 단일서버행/reloadqueue0. 소스1 소스2
8. 필수 단언과 비동기 완료	P	initial-failure-durable-row, failed-flush-retains-row, second-recovery-persists-once, reload-keeps-one-session, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 동일 운동은 초기503과 recovery 재실패 동안 owner pending row 정확히1개로 남아야 한다. 소유 IndexedDB 행에 대응하는 대표 control 'case-015-duplicate-owner-pending-create'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 5개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 11826ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적: 기본expect/action/navigation은각10초이고이spec의명시적대기상향은10초이하이며test timeout60초를상속한다. 같은조건의자동CASE재실행으로대기상한을늘리지않는다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-15"></a> <details><summary>CASE-016 — Desktop first plan create save crash and Home lockout (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 사용자는 운동일지에서 종목 A·B·C와 자유 기록 D로 새 운동 계획을 작성해 저장한 뒤 앱이 꺼지지 않고 바로 계획 카드를 볼 수 있으며, 새로고침 후에도 홈과 운동일지가 이번 달 계획 카드와 함께 정상적으로 열리고 저장한 종목·세트·자유 기록이 그대로 다시 보인다. 실제정상경로는브라우저·인증API/직접DB단언에연결되고추가control은dom 경계로선언된다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. 고정과거연도나이전CASE데이터를필수전제로쓰지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: 아래구간에서응답·표시상태·DB revision/저장행을단언후다음행동을한다. 공통요청drain은관측중요청의종료만검사하며목표UI/DB준비를대신하지않는다. 소스1 소스2
5. 독립적인 정답	P	정적: 명시된 A/B/C 세트와 note D로 독립 expectedSetRows를 구성하여 UI입력·RPC·직접 DB의 세트 필드/자유기록을 비교하고 수정시 expected+1 revision을 검사한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Desktop first plan create save crash and Home lockout: 실제 완료한 필수 상황·목표 checkpoint는 save-shell-alive, home-reload-with-plan, existing-plan-edit-and-reentry, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 새 계획 저장 후 reload에서도 Home/일지가 접근 가능하고 저장한 계획에 진입할 수 있어야 한다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적: create뒤 scrim0/홈·일지 정상, 자유기록과동적catalog, reload계획카드, 기존계획제목·첫중량수정/구child삭제와 재진입. 소스1 소스2
8. 필수 단언과 비동기 완료	P	save-shell-alive, home-reload-with-plan, existing-plan-edit-and-reentry, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 새 계획 저장 후 reload에서도 Home/일지가 접근 가능하고 저장한 계획에 진입할 수 있어야 한다. 실제 DOM에 대응하는 대표 control 'case-016-saved-plan-home-remains-locked'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 8807ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적: 기본expect/action/navigation은각10초이고이spec의명시적대기상향은10초이하이며test timeout60초를상속한다. 같은조건의자동CASE재실행으로대기상한을늘리지않는다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-16"></a> <details><summary>CASE-017 — Account deletion round trip (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 로그인한 사용자가 확인 문구와 함께 계정 삭제를 요청하면 한 번의 요청으로 본인 Auth 계정과 데이터가 삭제되고 다른 사용자는 보존되어야 한다. 이 CASE는 직접 만든 완료 운동의 session·session_exercise_part·exercise_set_part 전체 원본과 공통 계정 잔존 검사 대상(profiles·body_metrics·user_manual_pr_records·user_consents·달력 파생 행), 스토리지 3버킷 개인 폴더의 삭제를 확인한다. 대조 사용자의 Auth·프로필·운동 전체 원본·스토리지 파일과 재진입 화면이 그대로 유지되는지도 확인한다. 현재 명세와 실제 검사 계층을 대조했다. 실행 합격 판정은 별도 U 항목에 남긴다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. 고정과거연도나이전CASE데이터를필수전제로쓰지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: 아래구간에서응답·표시상태·DB revision/저장행을단언후다음행동을한다. 공통요청drain은관측중요청의종료만검사하며목표UI/DB준비를대신하지않는다. 소스1 소스2
5. 독립적인 정답	P	정적 보강 확인: 삭제 전 대상74×5/대조58×8와 owner/행 개수를 독립 값으로 확인한다. 삭제 뒤 대상 child id는 직접 부재를 조회하고, 대조 session/part/set·profile 전체를 검증된 삭제 전 값과 비교한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Account deletion round trip: 실제 완료한 필수 상황·목표 checkpoint는 predelete-isolated-state, in-app-deletion-round-trip, control-render-reentry, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 계정 삭제 후 세 bucket의 해당 사용자 prefix에 파일이 남지 않아야 한다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 보강 확인: 대상 Auth/명시 DB 범위/3 bucket의 삭제와 대조 Auth/profile/운동 전체 원본/파일·reload 보존을 명시한다. 대상 child 직접 잔존 조회와 대조 전체 비교가 추가됐다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	predelete-isolated-state, in-app-deletion-round-trip, control-render-reentry, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 계정 삭제 후 세 bucket의 해당 사용자 prefix에 파일이 남지 않아야 한다. 소유 저장소 서비스에 대응하는 대표 control 'case-017-account-delete-leaves-storage-object'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 3개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 6256ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적: 기본expect/action/navigation은각10초이고이spec의명시적대기상향은10초이하이며test timeout60초를상속한다. 같은조건의자동CASE재실행으로대기상한을늘리지않는다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-17"></a> <details><summary>CASE-018 — UGC report and block round trip (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 팔로우한 사용자의 포스트를 신고하면 신고자 피드에서 즉시 사라지고(D3), 차단하면 양방향 팔로우가 해제되며 재부팅 후에도 서버 필터가 그 사용자의 콘텐츠를 계속 걸러야 한다(D1). 관리자는 신고 큐에서 접수 건을 확인해 콘텐츠를 원본 불변으로 내리고(D4) 사용자를 정지·해제할 수 있어야 하며(D5), 금칙어 댓글은 서버가 거부해야 한다(D6). 실제정상경로는브라우저·인증API/직접DB단언에연결되고추가control은http-response 경계로선언된다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. 고정과거연도나이전CASE데이터를필수전제로쓰지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: 아래구간에서응답·표시상태·DB revision/저장행을단언후다음행동을한다. 공통요청drain은관측중요청의종료만검사하며목표UI/DB준비를대신하지않는다. 소스1 소스2
5. 독립적인 정답	P	정적: 실제 friend 두포스트·양방향follow를 준비해 신고1건의 target/reason/status, follow0, 원본immutable·takedown1 및 명시적 suspension/profanity거부 결과를 기대한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	UGC report and block round trip: 실제 완료한 필수 상황·목표 checkpoint는 feed-baseline, report-immediate-hide, block-round-trip, admin-moderation, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 차단은 실제 준비된 양방향 follow를 모두 제거해야 한다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적: 신고자의포스트숨김·다른포스트잔존, 차단양방향follow0와reload필터, 관리자접수/원본보존·정지/해제·금칙/정상댓글. 소스1 소스2
8. 필수 단언과 비동기 완료	P	feed-baseline, report-immediate-hide, block-round-trip, admin-moderation, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 차단은 실제 준비된 양방향 follow를 모두 제거해야 한다. SDK가 읽는 실제 HTTP 응답1건에 대응하는 대표 control 'case-018-block-leaves-reverse-follow'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. HTTP 응답 경계의 결함 검출이며 실제 DB 제약을 제거한 제품 결함 실험으로 확대하지 않는다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 4개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 4181ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적: 기본expect/action/navigation은각10초이고이spec의명시적대기상향은10초이하이며test timeout60초를상속한다. 같은조건의자동CASE재실행으로대기상한을늘리지않는다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-18"></a> <details><summary>CASE-019 — Group board percent round trip (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 화이트보드에 %로 입력한 세트는 %(원본)로 표시·저장·수정 재진입까지 유지되고(D3), kg 세트 상태에서 % 탭 전환만 해도 환산 %가 실체화되며(D3 후속), 셸 시작 바로 시작한 실제 운동 진행은 시작하는 사람 자신의 1RM으로 환산한 kg로 프리필돼야 한다(이슈 #1150 — 작성자의 환산 kg가 아니라, 작성자가 켠 5kg 반올림은 함께 적용). 스냅샷에는 load_pct(원본 %)와 load(작성자 환산 kg)가 병존해야 한다. 실제정상경로는브라우저·인증API/직접DB단언에연결되고추가control은dom 경계로선언된다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. 고정과거연도나이전CASE데이터를필수전제로쓰지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: 아래구간에서응답·표시상태·DB revision/저장행을단언후다음행동을한다. 공통요청drain은관측중요청의종료만검사하며목표UI/DB준비를대신하지않는다. 소스1 소스2
5. 독립적인 정답	P	정적: 실제 1RM200에 70%=140, 다른 작성자73%와5kg반올림은 사용자200의145kg라는 독립 상수를 UI/DB에서 기대한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Group board percent round trip: 실제 완료한 필수 상황·목표 checkpoint는 provisioning, board-percent-compose, snapshot-and-reload, reentry, member-own-1rm-prefill, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 회원 자신의1RM200·처방73%·5kg 반올림으로145kg를 prefill하며 작성자999kg를 가져오면 안 된다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적: kg→% 전환원본값, %표시·DBload_pct/load병존·edit/reload, coach의999kg가 아닌회원145kg프리필. 소스1 소스2
8. 필수 단언과 비동기 완료	P	provisioning, board-percent-compose, snapshot-and-reload, reentry, member-own-1rm-prefill, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 회원 자신의1RM200·처방73%·5kg 반올림으로145kg를 prefill하며 작성자999kg를 가져오면 안 된다. 실제 DOM에 대응하는 대표 control 'case-019-coach-kg-leaks-into-member-prefill'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 8421ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적: 기본expect/action/navigation은각10초이고이spec의명시적대기상향은10초이하이며test timeout60초를상속한다. 같은조건의자동CASE재실행으로대기상한을늘리지않는다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-19"></a> <details><summary>CASE-020 — Group board composite round trip (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 복합종목 빌더는 구성 2개 미만에서는 추가를 잠그고, 5개를 채우면 추가를 허용하되 여섯 번째 구성 슬롯을 만들 수 없어야 한다. 이 CASE의 저장·표시·수정 재진입·세션 프리필 왕복은 두 구성 종목으로 검증한다. 화이트보드에 올린 두 구성 종목은 구성 종목 배열(composite)과 세트의 동작별 값 묶음(parts)까지 저장·표시·수정 재진입·세션 프리필 전 층에서 유지돼야 한다. 스냅샷에는 parts(동작별)와 reps(합계)가 병존하고, 보드 세트 축약은 합계가 아니라 "10+10"으로 그려지며, 시작 바 프리필은 복합 카드와 동작별 반복을 그대로 실은 라이브 세션을 연다. 현재 명세와 실제 검사 계층을 대조했다. 실행 합격 판정은 별도 U 항목에 남긴다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. 고정과거연도나이전CASE데이터를필수전제로쓰지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: 아래구간에서응답·표시상태·DB revision/저장행을단언후다음행동을한다. 공통요청drain은관측중요청의종료만검사하며목표UI/DB준비를대신하지않는다. 소스1 소스2
5. 독립적인 정답	P	정적: 서로다른2종목과 parts=[10,10], reps합계20, load20을 명시해 DB/보드/수정편집/시작프리필의 동일값을 검사한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Group board composite round trip: 실제 완료한 필수 상황·목표 checkpoint는 provisioning, board-composite-compose, snapshot-and-reload, reentry-and-prefill, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 복합2개 구성과 동작별 parts의10+10을 보존해야 하며 합계 reps20만으로 대체할 수 없다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 보강 확인: 빌더 0/1개 상태에서 잠김, 2개 허용, 각 새 빈 슬롯 잠김, 5개 채움/여섯 슬롯 추가 부재를 단언한다. 다시 2개로 돌아와 원래 두 구성 저장·parts·reload·prefill을 보존한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	provisioning, board-composite-compose, snapshot-and-reload, reentry-and-prefill, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 복합2개 구성과 동작별 parts의10+10을 보존해야 하며 합계 reps20만으로 대체할 수 없다. SDK가 읽는 실제 HTTP 응답1건에 대응하는 대표 control 'case-020-composite-loses-second-movement-values'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. HTTP 응답 경계의 결함 검출이며 실제 DB 제약을 제거한 제품 결함 실험으로 확대하지 않는다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 6583ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적: 기본expect/action/navigation은각10초이고이spec의명시적대기상향은10초이하이며test timeout60초를상속한다. 같은조건의자동CASE재실행으로대기상한을늘리지않는다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-20"></a> <details><summary>CASE-021 — Live composite load gate round trip (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 라이브 복합종목 세트는 동작별 반복이 차 있어도 무게가 명시 입력(맨몸은 0)되기 전에는 '세트 설정 완료'가 잠기고, 편집을 통과한 세트는 알럿 없이 완료·저장까지 관통한다. 유효한 세트에 '세트 실패'를 잘못 눌러도 세트를 되돌려 다시 완료하면 실패 흔적이 남지 않으며, 저장된 두 동작 행은 모두 load 20·reps 10·set_result completed로 남는다. 실제정상경로는브라우저·인증API/직접DB단언에연결되고추가control은dom 경계로선언된다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. 고정과거연도나이전CASE데이터를필수전제로쓰지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: 아래구간에서응답·표시상태·DB revision/저장행을단언후다음행동을한다. 공통요청drain은관측중요청의종료만검사하며목표UI/DB준비를대신하지않는다. 소스1 소스2
5. 독립적인 정답	P	정적: 빈중량은disabled, 명시0은enabled, 지운뒤disabled,20은enabled 및 저장두행 각각20×10/completed를 독립 상수로 기대한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Live composite load gate round trip: 실제 완료한 필수 상황·목표 checkpoint는 composite-editor-load-gate, fail-tap-redo-clean, save-and-reload, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 복합 동작별 reps가 있어도 중량이 빈 값이면 저장이 잠겨야 하며 명시0은 허용한다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적: empty와0구별, 두동작입력, 잘못된실패→되돌림→완료로실패표식제거, 저장완료두행·reload. 소스1 소스2
8. 필수 단언과 비동기 완료	P	composite-editor-load-gate, fail-tap-redo-clean, save-and-reload, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 복합 동작별 reps가 있어도 중량이 빈 값이면 저장이 잠겨야 하며 명시0은 허용한다. 실제 DOM에 대응하는 대표 control 'case-021-blank-composite-load-gate-opens'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 6443ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적: 기본expect/action/navigation은각10초이고이spec의명시적대기상향은10초이하이며test timeout60초를상속한다. 같은조건의자동CASE재실행으로대기상한을늘리지않는다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-21"></a> <details><summary>CASE-022 — Live mixed composite round trip (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 이종 복합(무게×횟수 동작 + 시간 동작)은 편집기가 동작별로 자기 기록 원자만 묻고(공유 무게칸 없음), 전 동작의 논리식이 충족돼야 저장이 열리며, 완료 저장은 동작별 행에 자기 원자만 기입한다 — 무게 동작 행은 60kg·5회, 시간 동작 행은 30초에 횟수 없음. 리로드 후 세션 상세까지 왕복이 유지된다. 실제정상경로는브라우저·인증API/직접DB단언에연결되고추가control은http-response 경계로선언된다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. 고정과거연도나이전CASE데이터를필수전제로쓰지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: 아래구간에서응답·표시상태·DB revision/저장행을단언후다음행동을한다. 공통요청drain은관측중요청의종료만검사하며목표UI/DB준비를대신하지않는다. 소스1 소스2
5. 독립적인 정답	P	정적: 강도동작60×5와시간동작30초의독립상수, 서로의비관련atom은null을 DB원본에 대조한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Live mixed composite round trip: 실제 완료한 필수 상황·목표 checkpoint는 mixed-editor-per-movement-atoms, movement-rows-own-atoms, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 시간 전용 hold 행은30초·reps null·load null이어야 한다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 보강 확인: shared load input 부재와 개별 입력3개를 확인한다. strength60×5와 duration30초가 다른 원자에 섞이지 않으며 reload 상세60kg와30초를 모두 단언한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	mixed-editor-per-movement-atoms, movement-rows-own-atoms, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 시간 전용 hold 행은30초·reps null·load null이어야 한다. SDK가 읽는 실제 HTTP 응답1건에 대응하는 대표 control 'case-022-strength-load-contaminates-duration-row'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. HTTP 응답 경계의 결함 검출이며 실제 DB 제약을 제거한 제품 결함 실험으로 확대하지 않는다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 6688ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적: 기본expect/action/navigation은각10초이고이spec의명시적대기상향은10초이하이며test timeout60초를상속한다. 같은조건의자동CASE재실행으로대기상한을늘리지않는다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-22"></a> <details><summary>CASE-023 — Completed session follow-up edit write source (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 라이브 운동을 마치면 완료 화면에서 기록이 즉시 저장되고, 그 화면에서 메모를 고쳐 '메인으로'를 눌러도, 일지에서 그 기록을 열어 세트 무게를 고쳐 저장하고 곧바로 한 번 더 고쳐 저장해도 사용자에게 보이는 오류(배너·토스트·알럿)가 한 번도 뜨지 않는다. 저장마다 서버 개정번호가 1→2→3→4로 오르고, 종목 줄·세트 줄 id는 세 번의 수정 내내 그대로이며, 마지막 무게 85kg·60kg이 리로드 뒤 상세에 그대로 보인다. 실제정상경로는브라우저·인증API/직접DB단언에연결되고추가control은http-response 경계로선언된다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. 고정과거연도나이전CASE데이터를필수전제로쓰지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: 아래구간에서응답·표시상태·DB revision/저장행을단언후다음행동을한다. 공통요청drain은관측중요청의종료만검사하며목표UI/DB준비를대신하지않는다. 소스1 소스2
5. 독립적인 정답	P	정적: 초기세트상수와note,80/85kg후속입력 및revision1→2→3→4를 기대하고 검증된초기child id를매저장비교한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Completed session follow-up edit write source: 실제 완료한 필수 상황·목표 checkpoint는 auto-save-and-note-follow-up, consecutive-set-edits, reload-reentry, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 연속 수정 뒤 revision4여도 처음 만든 세트/종목 행 id를 유지해야 한다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적: 자동저장·note-only·연속2회세트수정, 기존child id·미변경세트·메모유지,오류0와reload두행각값. 소스1 소스2
8. 필수 단언과 비동기 완료	P	auto-save-and-note-follow-up, consecutive-set-edits, reload-reentry, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 연속 수정 뒤 revision4여도 처음 만든 세트/종목 행 id를 유지해야 한다. SDK가 읽는 실제 HTTP 응답1건에 대응하는 대표 control 'case-023-follow-up-recreates-child-row-identity'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. HTTP 응답 경계의 결함 검출이며 실제 DB 제약을 제거한 제품 결함 실험으로 확대하지 않는다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 11049ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적: 기본expect/action/navigation은각10초이고이spec의명시적대기상향은10초이하이며test timeout60초를상속한다. 같은조건의자동CASE재실행으로대기상한을늘리지않는다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-23"></a> <details><summary>CASE-024 — Completed record two-way edit round trip (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 완료된 기록은 (a) 수정 편집기로 세트 값을 고쳐 저장해도, (b) 종목을 전혀 건드리지 않고 시간만 또는 메모만 고쳐 저장해도 사용자에게 보이는 오류(배너·토스트·알럿)가 한 번도 뜨지 않는다. 세 저장 모두 서버 개정번호가 1→2→3→4로 오르고 종목 줄·세트 줄 id는 처음 만든 그대로이며, 리로드 뒤 상세에 80kg·10:00~11:00·새 메모가 그대로 보인다. 실제정상경로는브라우저·인증API/직접DB단언에연결되고추가control은http-response 경계로선언된다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. 고정과거연도나이전CASE데이터를필수전제로쓰지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: 아래구간에서응답·표시상태·DB revision/저장행을단언후다음행동을한다. 공통요청drain은관측중요청의종료만검사하며목표UI/DB준비를대신하지않는다. 소스1 소스2
5. 독립적인 정답	P	정적: 초기60kg등상수에서첫load80,시간10:00~11:00,새note를입력하고revision2/3/4와기존child id를검사한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Completed record two-way edit round trip: 실제 완료한 필수 상황·목표 checkpoint는 provisioning, set-value-edit, time-and-note-only-edits, reload-reentry, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 세트를 건드리지 않은 note-only 저장도 새 note와 revision4를 유지해야 한다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적: 세트수정/시간-only/note-only 세갈래에서 id·비관련값·완료상태유지,에러0와reload수정중량시간note. 소스1 소스2
8. 필수 단언과 비동기 완료	P	provisioning, set-value-edit, time-and-note-only-edits, reload-reentry, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 세트를 건드리지 않은 note-only 저장도 새 note와 revision4를 유지해야 한다. SDK가 읽는 실제 HTTP 응답1건에 대응하는 대표 control 'case-024-note-only-save-keeps-old-metadata'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. HTTP 응답 경계의 결함 검출이며 실제 DB 제약을 제거한 제품 결함 실험으로 확대하지 않는다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 8158ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적: 기본expect/action/navigation은각10초이고이spec의명시적대기상향은10초이하이며test timeout60초를상속한다. 같은조건의자동CASE재실행으로대기상한을늘리지않는다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-24"></a> <details><summary>CASE-025 — Plan to live session completion round trip (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 오늘 계획을 모바일 계획 편집기로 저장하고, 새로 연 앱의 시작 화면에서 그 계획을 골라 운동을 시작하면 세트가 계획대로 프리필된다. 운동을 마쳐 완료 화면에 들어오면 기록이 즉시 저장되고 계획은 completed로 닫히며, 완료 화면에서 메모를 고쳐 '메인으로'를 눌러도 오류가 뜨지 않는다. 완료 기록은 계획 제목·종목·50kg×5 세트를 그대로 싣고, 리로드 뒤 상세에도 그대로 보인다. 실제정상경로는브라우저·인증API/직접DB단언에연결되고추가control은http-response 경계로선언된다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. 고정과거연도나이전CASE데이터를필수전제로쓰지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: 아래구간에서응답·표시상태·DB revision/저장행을단언후다음행동을한다. 공통요청drain은관측중요청의종료만검사하며목표UI/DB준비를대신하지않는다. 소스1 소스2
5. 독립적인 정답	P	정적: 모바일계획50×5상수와동일plan id,planned→completed,revision1→2→3,note와child불변을직접확인한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Plan to live session completion round trip: 실제 완료한 필수 상황·목표 checkpoint는 plan-save, start-from-plan-and-complete, reload-reentry, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 계획으로 시작한 운동이 완료 저장되면 같은 plan id가completed로 닫혀야 한다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적: 계획실제UI생성·새앱선택·프리필·완료즉시저장·notefollowup,같은plan닫힘·reload완료행. 소스1 소스2
8. 필수 단언과 비동기 완료	P	plan-save, start-from-plan-and-complete, reload-reentry, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 계획으로 시작한 운동이 완료 저장되면 같은 plan id가completed로 닫혀야 한다. SDK가 읽는 실제 HTTP 응답1건에 대응하는 대표 control 'case-025-completed-workout-leaves-plan-open'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. HTTP 응답 경계의 결함 검출이며 실제 DB 제약을 제거한 제품 결함 실험으로 확대하지 않는다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 8187ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적: 기본expect/action/navigation은각10초이고이spec의명시적대기상향은10초이하이며test timeout60초를상속한다. 같은조건의자동CASE재실행으로대기상한을늘리지않는다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-25"></a> <details><summary>CASE-026 — Group board workout follow-up edit round trip (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 그룹 화이트보드에 올린 세트(60kg×5)로 운동을 시작하면 세트가 그대로 프리필되고, 운동을 마쳐 완료 화면에 들어오면 기록이 'group-board:' 출처(source_ref)로 즉시 저장된다. 완료 화면에서 메모를 고쳐 '메인으로'를 눌러도 오류가 뜨지 않고 개정번호가 1→2로 오르며, 종목 줄·세트 줄 id와 출처는 그대로다. 리로드 뒤 상세에 종목명과 60kg이 보인다. 실제정상경로는브라우저·인증API/직접DB단언에연결되고추가control은http-response 경계로선언된다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. 고정과거연도나이전CASE데이터를필수전제로쓰지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: 아래구간에서응답·표시상태·DB revision/저장행을단언후다음행동을한다. 공통요청drain은관측중요청의종료만검사하며목표UI/DB준비를대신하지않는다. 소스1 소스2
5. 독립적인 정답	P	정적: 보드60×5·group-board:출처와revision1→2,note입력상수,최초확인child id 보존을독립적으로판정한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Group board workout follow-up edit round trip: 실제 완료한 필수 상황·목표 checkpoint는 provisioning, board-compose, board-workout-and-follow-up, reload-reentry, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 그룹 보드 운동의 note-only 후속 저장은 원래 group-board source_ref와 행 id를 보존해야 한다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적: 실제보드발행→프리필→즉시저장→note-only후속수정·원래탭복귀,동일출처/child id·reload. 소스1 소스2
8. 필수 단언과 비동기 완료	P	provisioning, board-compose, board-workout-and-follow-up, reload-reentry, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 그룹 보드 운동의 note-only 후속 저장은 원래 group-board source_ref와 행 id를 보존해야 한다. SDK가 읽는 실제 HTTP 응답1건에 대응하는 대표 control 'case-026-note-follow-up-loses-group-board-lineage'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. HTTP 응답 경계의 결함 검출이며 실제 DB 제약을 제거한 제품 결함 실험으로 확대하지 않는다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 7873ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적: 기본expect/action/navigation은각10초이고이spec의명시적대기상향은10초이하이며test timeout60초를상속한다. 같은조건의자동CASE재실행으로대기상한을늘리지않는다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-26"></a> <details><summary>CASE-027 — Group board edit resave round trip (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 그룹 화이트보드에 세트(60kg×5)를 올린 뒤 앱을 새로 열어 보드로 돌아와 연필로 다시 들어가면 저장된 세트가 드로어에 60으로 복원되고, 무게를 80으로 고쳐 다시 올리면 오류 없이 보드가 '80kg 5x1'로 바뀐다. 같은 그룹 계획 세션 행(session, status=planned)의 get_group_board_v1 조회 결과가 load 80으로 갱신되고 updated_at이 전진하며, 리로드 뒤에도 80kg이 보인다. 현재 명세와 실제 검사 계층을 대조했다. 실행 합격 판정은 별도 U 항목에 남긴다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. 고정과거연도나이전CASE데이터를필수전제로쓰지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: 아래구간에서응답·표시상태·DB revision/저장행을단언후다음행동을한다. 공통요청drain은관측중요청의종료만검사하며목표UI/DB준비를대신하지않는다. 소스1 소스2
5. 독립적인 정답	P	정적: 초기60×5를80×5로수정하고같은행id/group/owner,새updated_at,DBload80과reload80을기대한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Group board edit resave round trip: 실제 완료한 필수 상황·목표 checkpoint는 provisioning, board-compose, board-edit-resave, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 보드를 60에서 80으로 수정한 뒤 같은 보드 id의 스냅샷도 80×5여야 한다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적: reload뒤기존60복원,두번째저장뒤이전60표시금지·정확1개보드행/id/소유자보존·최종reload80. 소스1 소스2
8. 필수 단언과 비동기 완료	P	provisioning, board-compose, board-edit-resave, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 보드를 60에서 80으로 수정한 뒤 같은 보드 id의 스냅샷도 80×5여야 한다. SDK가 읽는 실제 HTTP 응답1건에 대응하는 대표 control 'case-027-board-resave-retains-old-load'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. HTTP 응답 경계의 결함 검출이며 실제 DB 제약을 제거한 제품 결함 실험으로 확대하지 않는다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 6442ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적: 기본expect/action/navigation은각10초이고이spec의명시적대기상향은10초이하이며test timeout60초를상속한다. 같은조건의자동CASE재실행으로대기상한을늘리지않는다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-27"></a> <details><summary>CASE-028 — Finish back one more set resave round trip (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 라이브 운동을 종료하면 종료 확인 카드가 '저장 중 → 저장 완료'를 보여준 뒤 완료 화면이 뜨고(즉시 저장, 개정번호 1), 완료 화면의 '한 세트만 더할게요'로 기록 화면에 돌아가 세트를 하나 더 기록한 뒤 다시 종료해 '메인으로'를 누르면 세 번째 세트까지 포함한 수정 저장이 오류 없이 통과한다(개정번호 2). 새로 고침 뒤 상세에 세 세트가 모두 보인다(라이브 초안에서 나가는 재저장이라 줄 id는 새로 발급될 수 있고, 다음 수정은 저장된 기록의 상세에서 새 번호표로 열린다). 실제정상경로는브라우저·인증API/직접DB단언에연결되고추가control은dom 경계로선언된다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. 고정과거연도나이전CASE데이터를필수전제로쓰지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: 아래구간에서응답·표시상태·DB revision/저장행을단언후다음행동을한다. 공통요청drain은관측중요청의종료만검사하며목표UI/DB준비를대신하지않는다. 소스1 소스2
5. 독립적인 정답	P	정적: 60×5두행+추가70×5한행이라는정확입력상수와revision1→2를DB및reload세트별UI에기대한다. id교체허용정책과행개수보존을분리한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Finish back one more set resave round trip: 실제 완료한 필수 상황·목표 checkpoint는 auto-save-through-confirm-card, back-one-more-set-resave, reload-reentry, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 한 세트 더 기록하고 재저장한 뒤 reload 상세에는 60×5 두 개와 70×5 한 개가 모두 보여야 한다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 보강 확인: 실제 confirm 카드의 saving/aria-busy=true→saved/false 전이를 MutationObserver로 기록하고 완료 화면 뒤 배열을 단언한다. 별도 시간 고정 없이 기존 원본2세트+추가1세트/revision/reload 단언을 유지한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	auto-save-through-confirm-card, back-one-more-set-resave, reload-reentry, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 한 세트 더 기록하고 재저장한 뒤 reload 상세에는 60×5 두 개와 70×5 한 개가 모두 보여야 한다. 실제 DOM에 대응하는 대표 control 'case-028-resave-drops-original-two-sets-on-reentry'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 3개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 8319ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적: 기본expect/action/navigation은각10초이고이spec의명시적대기상향은10초이하이며test timeout60초를상속한다. 같은조건의자동CASE재실행으로대기상한을늘리지않는다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-28"></a> <details><summary>CASE-029 — Offline edit and delete queue flush round trip (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적: 완료된 운동 기록을 고쳐 저장하거나 삭제할 때 서버에 닿지 못해도(HTTP 503) 앱은 막지 않는다. 수정은 누르는 순간 '수정하였습니다'와 함께 편집기가 닫히고 기기 대기열에 수정 행 1개로 남으며 일지에는 '동기화 후 반영'으로 보이고 서버 내용은 그대로다. 연결이 돌아오면 자동으로 올라가 서버 무게가 80kg으로 바뀌고 대기열은 비며 '대기 중이던 기록 변경을 동기화했어요' 안내가 뜬다. 삭제도 같은 방식으로 '삭제하였습니다'와 함께 일지에서 즉시 사라진 뒤 대기열 삭제 행 1개로 남았다가 연결 복귀 시 서버에서 지워지고, 새로고침해도 그 기록은 없고 대기열도 비어 있다. 기존 계획 수정도 첫 실패 뒤 제목·세트를 기기에 보관하고 편집기를 닫는다. 열린 앱에서 새로고침 없이 같은 요청을 다시 보내 같은 계획의 제목·80kg×5가 서버와 UI에 반영되며, 성공 뒤 재진입해도 유지된다. 실제정상경로는브라우저·인증API/직접DB단언에연결되고추가control은indexeddb 경계로선언된다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적: CASE입력은자체fixture/명시상수로준비하며실행시각·SHA·locale·Seoul timezone·sessionDate를기록한다. 난수는주로소유id격리용이다. recovery clock은현재시각에서설치하고관측된재연결backoff만전진한다.200ms loop는상태재조회간격이며고정시간이끝났다는이유로준비완료라판정하지않는다. 소스1 소스2
3. 독립 실행	P	정적: caseContext는 매 CASE별 disposable Auth 계정과 runToken을 만들고 데이터·스토리지를 owner에 묶는다. 추가 actor도 본 CASE가 생성한다. 허용 runner는 lane별 port와 worker 1이며 CASE 간 실행 순서 의존을 확인하지 못했다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적: 아래구간에서응답·표시상태·DB revision/저장행을단언후다음행동을한다. 공통요청drain은관측중요청의종료만검사하며목표UI/DB준비를대신하지않는다. 소스1 소스2
5. 독립적인 정답	P	정적: 초기60×5두행과80kg수정입력,정확한pending1개/hash/body/id·서버revision증가,삭제후행0을기대하며gate전서버불변을직접읽는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Offline edit and delete queue flush round trip: 실제 완료한 필수 상황·목표 checkpoint는 online-baseline, edit-queued-on-device, edit-flushed-after-recovery, delete-queued-on-device, delete-flushed-and-reload, planned-edit-kept-on-device, planned-edit-replayed-and-reentry, journey-completion이다. 선언한 실패 completed-session-update-first-attempt-503:POST /rest/v1/rpc/save_session_v5; completed-session-delete-first-attempt-503:POST /rest/v1/rpc/delete_session_v5; planned-edit-first-direct-attempt-503:POST /rest/v1/rpc/save_session_v5의 실제 요청·시도 관측에서 missingAttempts/violations가 모두 비었다. 필수 복구 사건 observedCount=7와 누락/위반0도 확인했다. 목표: 실제 update 503 뒤 UI가 닫혀도 수정의 owner pending row 1개와 준비 request가 기기에 남아야 한다.의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적: 완료수정/삭제의각503→기기보관→연결복구,같은body재전송·child불변/삭제,별도계획첫실패와자동재전송·단일source·reload. 소스1 소스2
8. 필수 단언과 비동기 완료	P	online-baseline, edit-queued-on-device, edit-flushed-after-recovery, delete-queued-on-device, delete-flushed-and-reload, planned-edit-kept-on-device, planned-edit-replayed-and-reentry, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 실제 update 503 뒤 UI가 닫혀도 수정의 owner pending row 1개와 준비 request가 기기에 남아야 한다. 소유 IndexedDB 행에 대응하는 대표 control 'case-029-failed-update-loses-durable-pending-row'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 4개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 21111ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적: 기본expect/action/navigation은각10초이고이spec의명시적대기상향은10초이하이며test timeout60초를상속한다. 같은조건의자동CASE재실행으로대기상한을늘리지않는다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적: retries=0을 상속하고 CASE별 재시도 override가 없다. 내부 조건 poll은 동일 시도의 상태 관측이다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정적: 필수local환경은준비불가시config에서즉시실패하고reporter는skip/fixme/비최초성공을거부한다. 현spec에only나시간상향/무조건성공우회는없다. 예상오류는후속명시단언및공통gate로판정한다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-29"></a> <details><summary>CASE-030 — Assisted exercise effective load round trip (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 체중 80·보조 20·8회 입력부터 원자 저장/유효 부하와 상세 재진입까지 연결한다. 대표 control의 별도 경계 한계는 #9에 기록한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:03:00.780Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 assisted-set-record-and-save, reload-reentry, journey-completion의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 assisted-set-record-and-save, reload-reentry, journey-completion 완료를 대조했다. 이 CASE의 정리 resource 2개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 제어 확인: 홈·편집창·체크박스·완료 화면 상태와 실제 저장 revision을 확인한 뒤 DB 및 reload 상세로 진행한다. 실제 사건 발생 여부의 현재 실행 판정은 #6 U와 분리한다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: 80−20=60을 테스트 상수로 독립 계산하고 assist=20/load=null/reps=8/stats_load=0을 직접 비교한다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Assisted exercise effective load round trip: 실제 완료한 필수 상황·목표 checkpoint는 assisted-set-record-and-save, reload-reentry, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 보조 20kg을 유효 부하 60kg 대신 그대로 저장하는 계산 결함의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: 보조 입력 대신 일반 무게가 나타나지 않음, 종목·세트 각 1개, 잘못된 일반 kg 표시와 오류 부재를 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	assisted-set-record-and-save, reload-reentry, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 보조 20kg을 유효 부하 60kg 대신 그대로 저장하는 계산 결함 SDK가 읽는 실제 HTTP 응답1건에 대응하는 대표 control 'case030-purpose-control'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. HTTP 응답 경계의 결함 검출이며 실제 DB 제약을 제거한 제품 결함 실험으로 확대하지 않는다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 6160ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-30"></a> <details><summary>CASE-031 — Custom dumbbell exercise load multiplier round trip (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 커스텀 양손 덤벨 배수 선택→20kg×10→서버 유효 부하 40→상세 20kg 표시를 연결한다. 대표 control의 별도 경계 한계는 #9에 기록한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:03:07.174Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 custom-registration-with-multiplier, live-set-effective-load, reload-reentry, journey-completion의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 custom-registration-with-multiplier, live-set-effective-load, reload-reentry, journey-completion 완료를 대조했다. 이 CASE의 정리 resource 2개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 제어 확인: 실제 선택 속성·저장 행·홈·상세 상태를 기다리며 계산 응답 도착만으로 UI 준비를 대신하지 않는다. 실제 사건 발생 여부의 현재 실행 판정은 #6 U와 분리한다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: 20×2=40의 독립 상수 계산, reps=10 및 표시용 load=20·통계 400kg를 직접 단언한다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Custom dumbbell exercise load multiplier round trip: 실제 완료한 필수 상황·목표 checkpoint는 custom-registration-with-multiplier, live-set-effective-load, reload-reentry, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 덤벨 2개 배수를 무시해 유효 부하가 40kg 대신 20kg이 되는 결함의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: 배수 기본 1→선택 2, 보조 칸 없음, 카탈로그·세션 스냅샷, 단일 세트, 상세에 40kg 오표시 없음까지 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	custom-registration-with-multiplier, live-set-effective-load, reload-reentry, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 덤벨 2개 배수를 무시해 유효 부하가 40kg 대신 20kg이 되는 결함 SDK가 읽는 실제 HTTP 응답1건에 대응하는 대표 control 'case031-purpose-control'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. HTTP 응답 경계의 결함 검출이며 실제 DB 제약을 제거한 제품 결함 실험으로 확대하지 않는다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 6544ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-31"></a> <details><summary>CASE-032 — Finish-screen record delete closes immediately and the queued delete reaches the server once (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 삭제 ACK를 붙들고 완료 화면의 즉시 닫힘·상세 재조회 없음·대기열·단일 서버 삭제·재진입 부재를 검사한다. 대표 control의 별도 경계 한계는 #9에 기록한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:03:13.804Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 online-baseline, delete-closes-before-response, delete-reaches-server-once, reload-keeps-record-absent, journey-completion의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 online-baseline, delete-closes-before-response, delete-reaches-server-once, reload-keeps-record-absent, journey-completion 완료를 대조했다. 이 CASE의 정리 resource 3개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 제어 확인: 삭제 응답 gate가 닫힌 동안 화면 닫힘·요청 도착을 단언하고 gate 해제 후 서버·기기 종료를 확인한다. 실제 사건 발생 여부의 현재 실행 판정은 #6 U와 분리한다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: 사전 저장 60kg/개정 1, 요청 횟수 1, 삭제 후 행/자식/대기열 0을 독립 기대값으로 삼는다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Finish-screen record delete closes immediately and the queued delete reaches the server once: 실제 완료한 필수 상황·목표 checkpoint는 online-baseline, delete-closes-before-response, delete-reaches-server-once, reload-keeps-record-absent, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 기록 삭제 후 자식 세트가 남는 삭제 불완전성의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: 부모와 하위 행 삭제, 삭제 직전 detail RPC 증가 없음, reload 일지에서 제목/기록 없음, 빈 outbox를 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	online-baseline, delete-closes-before-response, delete-reaches-server-once, reload-keeps-record-absent, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 기록 삭제 후 자식 세트가 남는 삭제 불완전성 SDK가 읽는 실제 HTTP 응답1건에 대응하는 대표 control 'case032-purpose-control'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. HTTP 응답 경계의 결함 검출이며 실제 DB 제약을 제거한 제품 결함 실험으로 확대하지 않는다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 3개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 5991ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-32"></a> <details><summary>CASE-033 — Composite edit, set delete and day set count round trip (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 복합 운동 1세트→3세트→2세트와 세부 세트 2→6→4 및 일일 집계를 실제 UI·DB로 연결한다. 대표 control의 별도 경계 한계는 #9에 기록한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:03:19.956Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 composite-save-five-layers, edit-add-sets-day-count, edit-delete-set-day-count, reload-reentry, journey-completion의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 composite-save-five-layers, edit-add-sets-day-count, edit-delete-set-day-count, reload-reentry, journey-completion 완료를 대조했다. 이 CASE의 정리 resource 3개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 제어 확인: 수정 완료·서버 revision 전이·UI의 세트 개수와 실제 일일 RPC 집계를 기다린다. 실제 사건 발생 여부의 현재 실행 판정은 #6 U와 분리한다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: 예상 set position [1,2,3]→[1,2], part 수 2/6/4, 일일 집계 3/2는 입력과 계층 계약에서 독립적으로 정한다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Composite edit, set delete and day set count round trip: 실제 완료한 필수 상황·목표 checkpoint는 composite-save-five-layers, edit-add-sets-day-count, edit-delete-set-day-count, reload-reentry, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 복합 운동 세트 삭제 후 세 번째 세트가 남는 결함의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: 복합 부모/자식 연결 ID와 개수, 삭제된 한 세트, 세부 세트를 중복 집계하지 않는 총수 및 reload 종목 표시를 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	composite-save-five-layers, edit-add-sets-day-count, edit-delete-set-day-count, reload-reentry, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 복합 운동 세트 삭제 후 세 번째 세트가 남는 결함 SDK가 읽는 실제 HTTP 응답1건에 대응하는 대표 control 'case033-purpose-control'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. HTTP 응답 경계의 결함 검출이며 실제 DB 제약을 제거한 제품 결함 실험으로 확대하지 않는다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 3개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 13835ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-33"></a> <details><summary>CASE-034 — Plan partial completion same-row transition round trip (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 계획 두 세트 중 한 세트만 완료해 같은 행을 completed로 전이하고 미완료 세트/계획 카드를 없애는 목적이다. 대표 control의 별도 경계 한계는 #9에 기록한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:03:33.965Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 plan-save-and-card, partial-completion-transition, card-gone-day-count, reload-reentry, journey-completion의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 plan-save-and-card, partial-completion-transition, card-gone-day-count, reload-reentry, journey-completion 완료를 대조했다. 이 CASE의 정리 resource 3개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 제어 확인: 계획 카드·체크박스·완료 확인 및 실제 저장 revision 후 DB/홈 집계로 진행한다. 실제 사건 발생 여부의 현재 실행 판정은 #6 U와 분리한다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: 50kg×5, planned set 2→completed set 1, 같은 plan.id, revision 1→2와 일일 집계 1을 입력·계약으로 정한다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Plan partial completion same-row transition round trip: 실제 완료한 필수 상황·목표 checkpoint는 plan-save-and-card, partial-completion-transition, card-gone-day-count, reload-reentry, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 부분 완료 후 계획이 completed로 전이되지 않고 planned로 남는 결함의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: 동일 owner/date에 completed 행 한 개, 미완료 세트 삭제, 홈 계획 카드 제거, reload 상세 값을 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	plan-save-and-card, partial-completion-transition, card-gone-day-count, reload-reentry, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 부분 완료 후 계획이 completed로 전이되지 않고 planned로 남는 결함 SDK가 읽는 실제 HTTP 응답1건에 대응하는 대표 control 'case034-purpose-control'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. HTTP 응답 경계의 결함 검출이며 실제 DB 제약을 제거한 제품 결함 실험으로 확대하지 않는다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 3개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 8353ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-34"></a> <details><summary>CASE-035 — Group board member start and origin round trip (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 그룹장 보드에서 멤버가 시작한 개인 운동의 group-board 계보와 원래 보드 보존을 검사한다. 대표 control의 별도 경계 한계는 #9에 기록한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:03:42.531Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 board-as-planned-group-session, member-start-and-origin, group-day-sessions, reload-reentry, journey-completion의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 board-as-planned-group-session, member-start-and-origin, group-day-sessions, reload-reentry, journey-completion 완료를 대조했다. 이 CASE의 정리 resource 3개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 제어 확인: 초대 수락·보드·멤버 운동 완료를 실제 화면/행 관측으로 연결한다. 실제 사건 발생 여부의 현재 실행 판정은 #6 U와 분리한다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: 60kg×5와 origin_kind=group-board/origin_ref=그룹:날짜/group_id=null을 계약 상수와 준비 ID로 판정한다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Group board member start and origin round trip: 실제 완료한 필수 상황·목표 checkpoint는 board-as-planned-group-session, member-start-and-origin, group-day-sessions, reload-reentry, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 멤버 개인 운동이 그룹 계획 소유로 잘못 분류되는 결함의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: 멤버 개인 기록 한 세트, 원래 그룹장 보드 planned 유지, 완료 멤버 목록 및 보드 reload를 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	board-as-planned-group-session, member-start-and-origin, group-day-sessions, reload-reentry, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 멤버 개인 운동이 그룹 계획 소유로 잘못 분류되는 결함 SDK가 읽는 실제 HTTP 응답1건에 대응하는 대표 control 'case035-purpose-control'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. HTTP 응답 경계의 결함 검출이며 실제 DB 제약을 제거한 제품 결함 실험으로 확대하지 않는다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 3개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 8981ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-35"></a> <details><summary>CASE-036 — Retired write contract update notice round trip (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 최신 v5 정상 기록과 8개 퇴역 RPC의 LG426·무변경, 실제 브라우저 업데이트 안내/보존을 구분한다. 대표 control의 별도 경계 한계는 #9에 기록한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:03:51.654Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 v5-live-save, retired-rpcs-answer-lg426, reload-reentry, retired-contract-browser, journey-completion의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 v5-live-save, retired-rpcs-answer-lg426, reload-reentry, retired-contract-browser, journey-completion 완료를 대조했다. 이 CASE의 정리 resource 2개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 제어 확인: 실제 퇴역 RPC 400/LG426을 route.fetch로 받아 브라우저에 전달하고 요청 1회·blocked 값을 관측한다. 실제 사건 발생 여부의 현재 실행 판정은 #6 U와 분리한다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: 60kg×5/revision 1, 정확 SQLSTATE LG426와 update 메시지, blocked 상태 및 저장/receipt 0을 독립 계약으로 삼는다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Retired write contract update notice round trip: 실제 완료한 필수 상황·목표 checkpoint는 v5-live-save, retired-rpcs-answer-lg426, reload-reentry, retired-contract-browser, journey-completion이다. 선언한 실패 retired-contract-browser-response:POST /rest/v1/rpc/save_session_v5의 실제 요청·시도 관측에서 missingAttempts/violations가 모두 비었다. 필수 복구 사건 observedCount=1와 누락/위반0도 확인했다. 목표: 퇴역 RPC가 LG426 대신 일반 오류를 반환하는 계약 회귀의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: 퇴역 8개 모두 거절, 기존 revision·하위 ID 유지, 새 세션 없음, 브라우저 입력 보존 및 자동 재전송 없음까지 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	v5-live-save, retired-rpcs-answer-lg426, reload-reentry, retired-contract-browser, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 퇴역 RPC가 LG426 대신 일반 오류를 반환하는 계약 회귀 SDK가 읽는 실제 HTTP 응답1건에 대응하는 대표 control 'case036-purpose-control'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. HTTP 응답 경계의 결함 검출이며 실제 DB 제약을 제거한 제품 결함 실험으로 확대하지 않는다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 8701ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-36"></a> <details><summary>CASE-037 — Home favorite board shows exercise names on first paint while the exercise catalog response is still held (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 카탈로그 응답을 보류한 첫 표시와 reload에서 즐겨찾기 이름이 UUID 대신 표시되는 경계를 검사한다. 대표 control의 별도 경계 한계는 #9에 기록한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:04:00.536Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 board-names-without-catalog, names-stable-after-catalog, reload-paints-names-first, journey-completion의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 board-names-without-catalog, names-stable-after-catalog, reload-paints-names-first, journey-completion 완료를 대조했다. 이 CASE의 정리 resource 2개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 제어 확인: catalog route gate를 유지한 채 이름을 읽고 요청 도착·응답 해제·기존 이름 유지의 순서를 확인한다. 실제 사건 발생 여부의 현재 실행 판정은 #6 U와 분리한다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: 기준은 카탈로그에서 준비한 exercise.name, UUID 패턴 배제 및 ID 포함 금지이며 UI 자체를 정답으로 쓰지 않는다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Home favorite board shows exercise names on first paint while the exercise catalog response is still held: 실제 완료한 필수 상황·목표 checkpoint는 board-names-without-catalog, names-stable-after-catalog, reload-paints-names-first, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 카탈로그 대기 중 즐겨찾기에 운동 이름 대신 UUID가 보이는 결함의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: 빈 이름·UUID·ID 문자열 노출 금지, 즐겨찾기 API/서버 ID 일치, v4 이름 캐시 및 늦은 카탈로그/reload 보존을 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	board-names-without-catalog, names-stable-after-catalog, reload-paints-names-first, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 카탈로그 대기 중 즐겨찾기에 운동 이름 대신 UUID가 보이는 결함 실제 DOM에 대응하는 대표 control 'case037-purpose-control'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 3597ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-37"></a> <details><summary>CASE-038 — Creating a custom exercise pulls one catalog change page instead of the full catalog, and another user's custom exercise never invalidates my device copy (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 초기 전체 1회→내 생성 변경분 1회→타 사용자 생성 후 내 캐시/요청 불변을 구분해 검사한다. 대표 control의 별도 경계 한계는 #9에 기록한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:04:04.300Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 first-boot-full-catalog-once, custom-exercise-one-change-page, other-user-custom-no-request, journey-completion의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 first-boot-full-catalog-once, custom-exercise-one-change-page, other-user-custom-no-request, journey-completion 완료를 대조했다. 이 CASE의 정리 resource 2개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 제어 확인: 종목 생성과 변경분 완료를 관측한다. 2.5초 대기는 준비 완료 추정이 아닌 reload 뒤 추가 catalog RPC가 없어야 하는 유한 관찰창이다. 실제 사건 발생 여부의 현재 실행 판정은 #6 U와 분리한다. 소스1 소스2
5. 독립적인 정답	P	정적 독립 정답 확인: RPC가재전송한시스템종목을별도exercises(owner_user_id=null)조회로검증하고내custom ID만추가허용한다. 최대500ID를64개씩분할해모두검사하므로URL길이상한때문에검사목록을줄이지않는다. 타owner ID배제와latest_seq불변을보존한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Creating a custom exercise pulls one catalog change page instead of the full catalog, and another user's custom exercise never invalidates my device copy: 실제 완료한 필수 상황·목표 checkpoint는 first-boot-full-catalog-once, custom-exercise-one-change-page, other-user-custom-no-request, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 다른 사용자의 커스텀 종목이 내 변경 피드에 누출되는 소유권 결함의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: 양방향 타 사용자 종목 제외, 변경 로그 owner, 새로고침 추가 요청 0 및 picker 비노출을 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	first-boot-full-catalog-once, custom-exercise-one-change-page, other-user-custom-no-request, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	다른 사용자 운동이 내 증분 카탈로그에 포함되는 실제 SQL 결함을 정상→기존 목표 단언 실패→원본 복원 정상으로 확인했다. 실제 기대/관측값 불일치·정확한 최초 단언 위치·자동 재시도0·소유 자원 정리·SQL 정의/소유자/ACL 복원을 검증했다. 모든 가능한 결함을 증명하는 뜻은 아니다. 실제 SQL 주입·정확한 첫 예외·복원 readback은 원본 파일에 고정했고, 같은 후보의 공통 판정기 회귀가 미주입/생존/시간초과/다른 예외/정리 실패를 거절한 결과를 함께 대조했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 12922ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-38"></a> <details><summary>CASE-039 — Legacy tab and new tab share one pending-row store (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 실제 고정 legacy 번들/새 번들의 공유 IDB pending 정체성·추가 메타 보존·단일 적용을 검사한다. 새 writer 메타는 직접 주입한다고 명시한다. 대표 control의 별도 경계 한계는 #9에 기록한다. legacy는 이전에 배포된 고정 v0.17.1이며 현재 Production 버전이라는 의미가 아니다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:03:02.931Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 legacy-online-baseline, legacy-edit-queued, new-tab-reads-legacy-row, legacy-touches-row-again, single-server-apply, journey-completion의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 legacy-online-baseline, legacy-edit-queued, new-tab-reads-legacy-row, legacy-touches-row-again, single-server-apply, journey-completion 완료를 대조했다. 이 CASE의 정리 resource 8개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 확인: 실제 두 503·rehydrate gate·요청 횟수를 제어하고, 3초 구간은 새 탭 전송 부재의 유한 관찰창이다. 실제 connectivity probe 사건 사이의 backoff 입력만 진행하며 임의 달력 보정을 제거했다. 실제 완료는 새 실행 대기다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: 60→80/revision 1→2, 요청 ID/hash/body 불변, 고정 NEW_WRITER_META와 A3/B0을 독립 계약으로 삼는다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Legacy tab and new tab share one pending-row store: 실제 완료한 필수 상황·목표 checkpoint는 legacy-online-baseline, legacy-edit-queued, new-tab-reads-legacy-row, legacy-touches-row-again, single-server-apply, journey-completion이다. 선언한 실패 completed-session-update-503-legacy-twice:POST /rest/v1/rpc/save_session_v5의 실제 요청·시도 관측에서 missingAttempts/violations가 모두 비었다. 필수 복구 사건 observedCount=4와 누락/위반0도 확인했다. 목표: 새 탭이 옛 pending 행의 알 수 없는 claim 메타를 덮어쓰는 호환성 결함의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: 새 탭 전송0·unknown metadata 보존·단일 revision 증가·outbox/mirror 비움에 더해, reload 후 저장일의 상세 제목과 80kg×5회가 필수 단언으로 추가됐다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	legacy-online-baseline, legacy-edit-queued, new-tab-reads-legacy-row, legacy-touches-row-again, single-server-apply, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 새 탭이 옛 pending 행의 알 수 없는 claim 메타를 덮어쓰는 호환성 결함 소유 IndexedDB 행에 대응하는 대표 control 'case039-purpose-control'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 8개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 19773ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-39"></a> <details><summary>CASE-040 — Legacy tab in flight and new tab successor edit (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 실제 legacy in-flight 행과 새 탭 successor가 공유 IDB에서 공존하고 ACK 뒤 순차 반영되는 목적이다. 대표 control의 별도 경계 한계는 #9에 기록한다. legacy는 이전에 배포된 고정 v0.17.1이며 현재 Production 버전이라는 의미가 아니다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:03:30.292Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 new-tab-bootstrap-outage-then-legacy-online-baseline, legacy-edit-in-flight, new-tab-successor-kept, legacy-receipt-keeps-successor, successor-applied-after-predecessor, journey-completion의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 new-tab-bootstrap-outage-then-legacy-online-baseline, legacy-edit-in-flight, new-tab-successor-kept, legacy-receipt-keeps-successor, successor-applied-after-predecessor, journey-completion 완료를 대조했다. 이 CASE의 정리 resource 9개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 제어 확인: 선행 요청 보류/해제와 실제 ACK·DB revision·successor 생존을 순서로 묶는다. 1초는 후속 전송 부재의 유한 관찰창이다. 실제 사건 발생 여부의 현재 실행 판정은 #6 U와 분리한다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: 60→80→90, revision 1→2→3, 2개 pending→successor 1개→0, 새 mutation ID와 요청 본문 불변으로 판정한다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	Legacy tab in flight and new tab successor edit: 실제 완료한 필수 상황·목표 checkpoint는 new-tab-bootstrap-outage-then-legacy-online-baseline, legacy-edit-in-flight, new-tab-successor-kept, legacy-receipt-keeps-successor, successor-applied-after-predecessor, journey-completion이다. 선언한 실패 new-tab-bootstrap-503-twice:POST /rest/v1/rpc/get_profile_workspace; successor-stale-revision-conflict:POST /rest/v1/rpc/save_session_v5의 실제 요청·시도 관측에서 missingAttempts/violations가 모두 비었다. 필수 복구 사건 observedCount=2와 누락/위반0도 확인했다. 목표: 옛 탭 ACK가 새 successor 행까지 삭제하는 결함의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: 선행 ACK·successor 생존·충돌400→200·revision3에 더해 새 탭과 legacy 탭 각각 reload 후 저장일의 제목과 90kg×5회 상세를 확인한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	new-tab-bootstrap-outage-then-legacy-online-baseline, legacy-edit-in-flight, new-tab-successor-kept, legacy-receipt-keeps-successor, successor-applied-after-predecessor, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 옛 탭 ACK가 새 successor 행까지 삭제하는 결함 소유 IndexedDB 행에 대응하는 대표 control 'case040-purpose-control'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 9개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 17329ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-40"></a> <details><summary>CASE-041 — committed create edit and delete retry the identical mutation without applying twice (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 생성·수정·삭제를 실제 서버 commit한 뒤 ACK만 잃게 하여 같은 mutation 재전송의 단일 적용을 검사한다. 대표 control의 별도 경계 한계는 #9에 기록한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:04:17.406Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 checkpoint-1, checkpoint-2, checkpoint-3의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 checkpoint-1, checkpoint-2, checkpoint-3 완료를 대조했다. 이 CASE의 정리 resource 2개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 제어 확인: route.fetch 성공과 실제 receipt 존재 후 503을 전달하고 recovery gate 관측 뒤 재전송을 허용한다. 실제 사건 발생 여부의 현재 실행 판정은 #6 U와 분리한다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: 사전 receipt 불변은 재전송 불변식이고, 60/rev1→80/rev2→삭제 및 각 전송 2회는 별도 상수 단언이다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	committed create edit and delete retry the identical mutation without applying twice: 실제 완료한 필수 상황·목표 checkpoint는 checkpoint-1, checkpoint-2, checkpoint-3이다. 선언한 실패 create-ack-lost:POST /rest/v1/rpc/save_session_v5; edit-ack-lost:POST /rest/v1/rpc/save_session_v5; delete-ack-lost:POST /rest/v1/rpc/delete_session_v5의 실제 요청·시도 관측에서 missingAttempts/violations가 모두 비었다. 필수 복구 사건 observedCount=6와 누락/위반0도 확인했다. 목표: 동일 mutation 재전송이 최초 commit 영수증 revision을 다시 바꾸는 이중 적용 결함의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: 세 mutation의 같은 body 재전송, 서버/receipt 단일성, outbox 비움과 edit reload 값을 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	checkpoint-1, checkpoint-2, checkpoint-3 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	이미 반영한 create mutation의 재전송이 실제 session revision을 다시 증가시키는 SQL 결함을 정상→기존 목표 단언 실패→원본 복원 정상으로 확인했다. 실제 기대/관측값 불일치·정확한 최초 단언 위치·자동 재시도0·소유 자원 정리·SQL 정의/소유자/ACL 복원을 검증했다. 모든 가능한 결함을 증명하는 뜻은 아니다. 실제 SQL 주입·정확한 첫 예외·복원 readback은 원본 파일에 고정했고, 같은 후보의 공통 판정기 회귀가 미주입/생존/시간초과/다른 예외/정리 실패를 거절한 결과를 함께 대조했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 17127ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-41"></a> <details><summary>CASE-042 — a real sending row survives page death and its expired send is replayed by the next boot (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 실제 sending 행이 페이지 종료를 넘어 남고 실제 TTL 후 새 페이지가 같은 요청을 한 번 반영하는 경계다. 대표 control의 별도 경계 한계는 #9에 기록한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:04:34.670Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 checkpoint-1, checkpoint-2, checkpoint-3의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 checkpoint-1, checkpoint-2, checkpoint-3 완료를 대조했다. 이 CASE의 정리 resource 4개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 확인: 원래 sending row의 sentAt+10001ms 실제 만료 사건을 계산하고 최초 하나의 10초 deadline 안에서 기다린 뒤 기존 age>10000 단언을 실행한다. 반복 polling 끝 샘플이 9984ms여서 거짓 실패하던 관찰 방식은 제거했고 TTL/날짜/timeout을 상향하지 않았다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: 종료 전 요청 ID/hash/body 불변과 고정 60kg×5/rev1, session·receipt 1개를 함께 확인한다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	a real sending row survives page death and its expired send is replayed by the next boot: 실제 완료한 필수 상황·목표 checkpoint는 checkpoint-1, checkpoint-2, checkpoint-3이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 페이지 사망 뒤 복원된 pending 요청의 원래 입력이 변하는 결함의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: 죽은 페이지의 서버 미저장, 재시작 요청 불변, 빈 outbox와 단일 기록·receipt·상세 값을 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	checkpoint-1, checkpoint-2, checkpoint-3 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 페이지 사망 뒤 복원된 pending 요청의 원래 입력이 변하는 결함 소유 IndexedDB 행에 대응하는 대표 control 'case042-purpose-control'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 4개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 15201ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-42"></a> <details><summary>CASE-043 — the real server rejects an expired signed JWT and the same owner reauthenticates to resume the held mutation (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 로컬 서명 만료 JWT의 실제 서버 거절 뒤 동일 owner 재인증이 held 요청을 보존·업로드하는 범위다. 대표 control의 별도 경계 한계는 #9에 기록한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:04:50.014Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 checkpoint-1, checkpoint-2, checkpoint-3의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 checkpoint-1, checkpoint-2, checkpoint-3 완료를 대조했다. 이 CASE의 정리 resource 3개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 제어 확인: 첫 요청에 실제 서명 만료 토큰을 보내고 서버 오류·held 상태 확인 후 새 인증 및 resume gate를 해제한다. 실제 사건 발생 여부의 현재 실행 판정은 #6 U와 분리한다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: 정확 401/PGRST303 expired 및 owner ID, 원래 immutable request, 60kg×5/rev1을 독립 비교한다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	the real server rejects an expired signed JWT and the same owner reauthenticates to resume the held mutation: 실제 완료한 필수 상황·목표 checkpoint는 checkpoint-1, checkpoint-2, checkpoint-3이다. 선언한 실패 expired-jwt-write:POST /rest/v1/rpc/save_session_v5의 실제 요청·시도 관측에서 missingAttempts/violations가 모두 비었다. 목표: 같은 사용자 재인증 뒤 held 요청의 원래 입력이 유실되는 결함의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: 만료 상태의 서버/receipt 없음, 새 토큰 동일 owner, 원래 request 재생·단일 receipt/record·재진입을 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	checkpoint-1, checkpoint-2, checkpoint-3 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 같은 사용자 재인증 뒤 held 요청의 원래 입력이 유실되는 결함 소유 IndexedDB 행에 대응하는 대표 control 'case043-purpose-control'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 3개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 6885ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-43"></a> <details><summary>CASE-044 — A pending data stays private while B saves and only A reentry uploads A request (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: A held 데이터를 공유 기기에 남긴 채 B 로그인/저장과 A 재진입을 비교하여 UI·전송·서버 owner 격리를 검사한다. 대표 control의 별도 경계 한계는 #9에 기록한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:04:57.029Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 checkpoint-1, checkpoint-2, checkpoint-3, checkpoint-4의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 checkpoint-1, checkpoint-2, checkpoint-3, checkpoint-4 완료를 대조했다. 이 CASE의 정리 resource 4개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 제어 확인: 실제 JWT 401→held→페이지 닫힘→B의 실제 저장→A 재인증 원래 요청 재생을 관측한다. 실제 사건 발생 여부의 현재 실행 판정은 #6 U와 분리한다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: A/B의 별도 준비 ID, 전송 0/1, 원래 immutable request와 A/B 인증별 빈/단일 session 조회를 정답으로 삼는다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	A pending data stays private while B saves and only A reentry uploads A request: 실제 완료한 필수 상황·목표 checkpoint는 checkpoint-1, checkpoint-2, checkpoint-3, checkpoint-4이다. 선언한 실패 owner-a-expired-jwt:POST /rest/v1/rpc/save_session_v5의 실제 요청·시도 관측에서 missingAttempts/violations가 모두 비었다. 목표: A 기록이 B의 인증 조회에 나타나는 계정 격리 결함의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: B 화면 A 제목 부재·A 자동 전송 없음·B만 저장·A 복귀 전 미저장·양방향 서버 접근 차단을 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	checkpoint-1, checkpoint-2, checkpoint-3, checkpoint-4 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	사용자 교체 후 B의 실제 RLS reader가 A의 session을 반환하는 SQL 결함을 정상→기존 목표 단언 실패→원본 복원 정상으로 확인했다. 실제 기대/관측값 불일치·정확한 최초 단언 위치·자동 재시도0·소유 자원 정리·SQL 정의/소유자/ACL 복원을 검증했다. 모든 가능한 결함을 증명하는 뜻은 아니다. 실제 SQL 주입·정확한 첫 예외·복원 readback은 원본 파일에 고정했고, 같은 후보의 공통 판정기 회귀가 미주입/생존/시간초과/다른 예외/정리 실패를 거절한 결과를 함께 대조했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 4개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 11366ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-44"></a> <details><summary>CASE-045 — a later tab edit resolves a real revision conflict and an older late ACK cannot restore old values (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 동일 owner의 별도 browser context에서 실제 revision 충돌과 늦은 ACK를 제어하여 최신 편집/최종 삭제 수렴을 검사한다. 공유 IDB 직렬화는 CASE-040로 연결한다. 대표 control의 별도 경계 한계는 #9에 기록한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:05:08.599Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 checkpoint-1, checkpoint-2, checkpoint-3, checkpoint-4의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 checkpoint-1, checkpoint-2, checkpoint-3, checkpoint-4 완료를 대조했다. 이 CASE의 정리 resource 3개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 제어 확인: A 실제 commit 뒤 ACK 보류 중 B stale revision을 보내 400→200을 관측하고 write timeout 안에 A ACK를 해제한다. 실제 사건 발생 여부의 현재 실행 판정은 #6 U와 분리한다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: 60→70→80/rev3 및 최종 삭제, expected_revision 1→2/3→4, 개별 mutation ID를 독립 값으로 비교한다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	a later tab edit resolves a real revision conflict and an older late ACK cannot restore old values: 실제 완료한 필수 상황·목표 checkpoint는 checkpoint-1, checkpoint-2, checkpoint-3, checkpoint-4이다. 선언한 실패 real-stale-revision:POST /rest/v1/rpc/save_session_v5; real-stale-delete-revision:POST /rest/v1/rpc/delete_session_v5; deleted-record-detail:POST /rest/v1/rpc/get_session_detail의 실제 요청·시도 관측에서 missingAttempts/violations가 모두 비었다. 필수 복구 사건 observedCount=1와 누락/위반0도 확인했다. 목표: 실제 revision 충돌 복구 후 최신 80kg 대신 이전 탭의 70kg을 저장하는 경합 결함의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: 독립 queue·claim·mutations, 오래된 receipt revision, 양 context reload 최신값/삭제 부재를 검사한다. 현재 detail 검사는 표시될 때만 적용되지만 뒤의 reload 값 단언은 필수다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	checkpoint-1, checkpoint-2, checkpoint-3, checkpoint-4 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 실제 revision 충돌 복구 후 최신 80kg 대신 이전 탭의 70kg을 저장하는 경합 결함 SDK가 읽는 실제 HTTP 응답1건에 대응하는 대표 control 'case045-purpose-control'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. HTTP 응답 경계의 결함 검출이며 실제 DB 제약을 제거한 제품 결함 실험으로 확대하지 않는다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 3개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 14472ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-45"></a> <details><summary>CASE-046 — a permanent rejection is quarantined until the user uploads the preserved workout as a new record (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 영구 22023 거절을 격리하고 실제 사용자 복구 버튼으로 원래 내용을 새 identity로 한 번 업로드한다. 대표 control의 별도 경계 한계는 #9에 기록한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:03:53.737Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 checkpoint-1, checkpoint-2, checkpoint-3의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 checkpoint-1, checkpoint-2, checkpoint-3 완료를 대조했다. 이 CASE의 정리 resource 2개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 제어 확인: 첫 route 거절과 blocked 상태를 확인한 뒤 online 이벤트에도 전송 1회임을 보고 사용자 버튼으로 회복한다. 실제 사건 발생 여부의 현재 실행 판정은 #6 U와 분리한다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: 제목/60kg×5, blocked 상태, 이전 receipt0/새 receipt1, 새 mutation/source_ref 관계를 독립 판정한다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	a permanent rejection is quarantined until the user uploads the preserved workout as a new record: 실제 완료한 필수 상황·목표 checkpoint는 checkpoint-1, checkpoint-2, checkpoint-3이다. 선언한 실패 permanent-contract-rejection:POST /rest/v1/rpc/save_session_v5의 실제 요청·시도 관측에서 missingAttempts/violations가 모두 비었다. 필수 복구 사건 observedCount=1와 누락/위반0도 확인했다. 목표: 영구 거절로 격리된 기록의 제목이 유실되는 입력 보존 결함의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: 자동 재시도 없음, 서버 미저장·입력 보존·실제 복구 버튼, 새 ID 하나와 reload 값을 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	checkpoint-1, checkpoint-2, checkpoint-3 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 영구 거절로 격리된 기록의 제목이 유실되는 입력 보존 결함 소유 IndexedDB 행에 대응하는 대표 control 'case046-purpose-control'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 6956ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-46"></a> <details><summary>CASE-047 — an old detail response cannot replace the newer selected workout and a failed read can be retried (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 실제 이전 detail 응답을 늦추어 현재 선택 상세가 유지되고, 별도 조회 실패 후 로그인 유지·재조회가 성공하는 경계다. 대표 control의 별도 경계 한계는 #9에 기록한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:04:00.846Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 checkpoint-1, checkpoint-2, checkpoint-3의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 checkpoint-1, checkpoint-2, checkpoint-3 완료를 대조했다. 이 CASE의 정리 resource 2개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 제어 확인: 첫 실제 응답 확보→다른 기록 선택→oldDelivered 확인→현재 상세 유지, 별도 503→사용자 재조회 순서다. 실제 사건 발생 여부의 현재 실행 판정은 #6 U와 분리한다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: 준비한 first/second 제목과 60/80kg×5, 현재 owner를 독립 비교한다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	an old detail response cannot replace the newer selected workout and a failed read can be retried: 실제 완료한 필수 상황·목표 checkpoint는 checkpoint-1, checkpoint-2, checkpoint-3이다. 선언한 실패 detail-read-unavailable:POST /rest/v1/rpc/get_session_detail의 실제 요청·시도 관측에서 missingAttempts/violations가 모두 비었다. 필수 복구 사건 observedCount=1와 누락/위반0도 확인했다. 목표: 늦은 첫 기록 응답이 현재 두 번째 기록 제목을 덮어쓰는 결함의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: 늦은 이전 제목 배제, 실패 뒤 로그인 화면 없음/세션 유지, 재시도 응답 200 및 올바른 상세를 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	checkpoint-1, checkpoint-2, checkpoint-3 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 늦은 첫 기록 응답이 현재 두 번째 기록 제목을 덮어쓰는 결함 실제 DOM에 대응하는 대표 control 'case047-purpose-control'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 12471ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-47"></a> <details><summary>CASE-048 — cached HTTPS reentry and a real service worker update preserve one pending workout (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 실제 HTTPS service worker 캐시의 오프라인 새 페이지와 worker 교체 중 pending 보존·단일 반영을 검사한다. 대표 control의 별도 경계 한계는 #9에 기록한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:05:15.233Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 checkpoint-1, checkpoint-2, checkpoint-3, checkpoint-4의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 checkpoint-1, checkpoint-2, checkpoint-3, checkpoint-4 완료를 대조했다. 이 CASE의 정리 resource 3개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 제어 확인: native offline/online 상태, 실제 캐시 응답, 저장 요청 보류, worker activated/controllerchange 관측 후 ACK를 해제한다. 실제 사건 발생 여부의 현재 실행 판정은 #6 U와 분리한다. 캐시 준비 reload 전 현재 문서 catalog/month 응답200 및실제finished를확인하도록보강했다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: 동일 owner/request ID/hash/body, offline document가 SW에서 온 200, session/receipt 1개와 60kg×5를 독립 단언한다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	cached HTTPS reentry and a real service worker update preserve one pending workout: 실제 완료한 필수 상황·목표 checkpoint는 checkpoint-1, checkpoint-2, checkpoint-3, checkpoint-4이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 필수 복구 사건 observedCount=6와 누락/위반0도 확인했다. 목표: 서비스워커 교체가 ACK 전 pending 기록을 지우는 결함의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: 오프라인 서버 미저장, 네트워크 문서 요청 없음, 실제 controllerchange, pending 불변·중복 전송 없음·reload를 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	checkpoint-1, checkpoint-2, checkpoint-3, checkpoint-4 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 서비스워커 교체가 ACK 전 pending 기록을 지우는 결함 소유 IndexedDB 행에 대응하는 대표 control 'case048-purpose-control'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 3개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 11454ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-48"></a> <details><summary>CASE-049 — CASE-049 a cancelled provider callback leaves login available and a retried callback restores the same real account (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: Kakao 제공자 경계의 제어된 취소/PKCE 실패/성공 복귀 후 실제 Auth owner와 기존 신원을 검사한다. 외부 제공자 화면 완주가 아님을 manifest에 명시한다. 대표 control의 별도 경계 한계는 #9에 기록한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:04:13.483Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 checkpoint-1, rejected-exchange, checkpoint-2, checkpoint-3, journey-completion의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 checkpoint-1, rejected-exchange, checkpoint-2, checkpoint-3, journey-completion 완료를 대조했다. 이 CASE의 정리 resource 2개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 제어 확인: provider route의 정확 challenge·auth_code와 요청 카운터, 화면·Auth 저장 상태를 사건별로 관측한다. 실제 사건 발생 여부의 현재 실행 판정은 #6 U와 분리한다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: 취소/실패 단계 세션없음, auth 횟수3/exchange2, 준비 owner와 검증된 기존 identity 목록을 불변 정답으로 사용한다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	CASE-049 a cancelled provider callback leaves login available and a retried callback restores the same real account: 실제 완료한 필수 상황·목표 checkpoint는 checkpoint-1, rejected-exchange, checkpoint-2, checkpoint-3, journey-completion이다. 선언한 실패 rejected-pkce-exchange:POST /auth/v1/token?grant_type=pkce의 실제 요청·시도 관측에서 missingAttempts/violations가 모두 비었다. 필수 복구 사건 observedCount=1와 누락/위반0도 확인했다. 목표: 취소 후 재로그인이 기존 identity 목록을 잃는 인증 회귀의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: URL code/error 제거, 실패 후 버튼 활성·home없음, 기존 profile·identity 보존 및 reload에서 복귀 재실행 없음까지 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	checkpoint-1, rejected-exchange, checkpoint-2, checkpoint-3, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 취소 후 재로그인이 기존 identity 목록을 잃는 인증 회귀 SDK가 읽는 실제 HTTP 응답1건에 대응하는 대표 control 'case049-purpose-control'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. HTTP 응답 경계의 결함 검출이며 실제 DB 제약을 제거한 제품 결함 실험으로 확대하지 않는다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 5229ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-49"></a> <details><summary>CASE-050 — CASE-050 profile edit failures preserve the draft and retry persists the name handle and photo (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 아이디 저장 실패 중 UI 잠금·draft 보존과 실제 재시도 이후 이름/아이디/사진 저장 및 reload를 검사한다. 대표 control의 별도 경계 한계는 #9에 기록한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:04:19.000Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 feature-round-trip, journey-completion의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 feature-round-trip, journey-completion 완료를 대조했다. 이 CASE의 정리 resource 2개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 제어 확인: 실제 첫 handle 요청 도착을 기다린 뒤 보류 중 잠금, 명시 오류 전달 후 draft/재시도 완료를 확인한다. 실제 사건 발생 여부의 현재 실행 판정은 #6 U와 분리한다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: 입력한 handle/name, 자신의 owner ID/path 접두사와 최초 avatar 없음이 독립 정답이다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	CASE-050 profile edit failures preserve the draft and retry persists the name handle and photo: 실제 완료한 필수 상황·목표 checkpoint는 feature-round-trip, journey-completion이다. 선언한 실패 declared-post-503-1:POST /rest/v1/rpc/set_profile_handle_v1의 실제 요청·시도 관측에서 missingAttempts/violations가 모두 비었다. 필수 복구 사건 observedCount=1와 누락/위반0도 확인했다. 목표: 실패 후 재시도 편집창의 아이디 draft가 유실되는 결함의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: 중복 제출/취소 잠금, draft보존, 부적합 사진 거절·기존 사진없음, 정상 사진 로드와 owner row/reload를 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	feature-round-trip, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 실패 후 재시도 편집창의 아이디 draft가 유실되는 결함 실제 DOM에 대응하는 대표 control 'case050-purpose-control'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 4352ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-50"></a> <details><summary>CASE-051 — CASE-051 an unsuccessful account link return preserves the original identity and permits profile reentry (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 제공자 실패 복귀 파라미터를 앱에 전달한 뒤 기존 login owner/identity 보존과 일회성 안내·URL 정리를 검사한다. 실제 외부 연결 과정은 범위 밖이다. 대표 control의 별도 경계 한계는 #9에 기록한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:04:23.487Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 feature-round-trip, journey-completion의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 feature-round-trip, journey-completion 완료를 대조했다. 이 CASE의 정리 resource 2개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 제어 확인: 복귀 URL을 실제 profile 흐름에서 소비한 뒤 toast/URL/Auth 재조회와 reload 상태를 확인한다. 실제 사건 발생 여부의 현재 실행 판정은 #6 U와 분리한다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: 준비한 owner와 비어있지 않은 기존 identity IDs, 정확 실패 안내/URL 파라미터 부재를 정답으로 삼는다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	CASE-051 an unsuccessful account link return preserves the original identity and permits profile reentry: 실제 완료한 필수 상황·목표 checkpoint는 feature-round-trip, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 필수 복구 사건 observedCount=1와 누락/위반0도 확인했다. 목표: 실패한 계정 연결이 원래 Auth identity를 제거하는 결함의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: 연결 해제 UI 미제공, 같은 Auth/profile owner, 신원 목록 불변, reload 후 안내 중복 발행 없음까지 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	feature-round-trip, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 실패한 계정 연결이 원래 Auth identity를 제거하는 결함 SDK가 읽는 실제 HTTP 응답1건에 대응하는 대표 control 'case051-purpose-control'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. HTTP 응답 경계의 결함 검출이며 실제 DB 제약을 제거한 제품 결함 실험으로 확대하지 않는다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 3814ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-51"></a> <details><summary>CASE-052 — CASE-052 failed likes roll back and failed comments retain their draft before successful UI retry (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 좋아요/댓글/팔로우의 첫 실패와 실제 UI 재시도·DB 단일 저장·reload를 연결한다. 대표 control의 별도 경계 한계는 #9에 기록한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:04:27.397Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 feature-round-trip, journey-completion의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 feature-round-trip, journey-completion 완료를 대조했다. 이 CASE의 정리 resource 2개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 제어 확인: 각 실패 요청의 started→잠금/낙관 표시→release→오류/복구 상태를 확인한다. 실제 사건 발생 여부의 현재 실행 판정은 #6 U와 분리한다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: aria-pressed false→true→false, 입력 comment와 owner/friend/session IDs, DB 각1개를 독립 기대값으로 삼는다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	CASE-052 failed likes roll back and failed comments retain their draft before successful UI retry: 실제 완료한 필수 상황·목표 checkpoint는 feature-round-trip, journey-completion이다. 선언한 실패 declared-post-403-1:POST /rest/v1/rpc/set_session_like_v1; declared-post-400-1:POST /rest/v1/rpc/add_session_comment_v1; declared-post-503-1:POST /rest/v1/rpc/unfollow_user_v1의 실제 요청·시도 관측에서 missingAttempts/violations가 모두 비었다. 필수 복구 사건 observedCount=3와 누락/위반0도 확인했다. 목표: 좋아요 실패 뒤 optimistic 선택 표시가 false로 되돌아오지 않는 결함의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: 보류 중 버튼잠금, 좋아요 rollback·실패 DB0, 댓글 draft 유지·중복0, 팔로우 실패 불변, reload 단일 댓글을 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	feature-round-trip, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 좋아요 실패 뒤 optimistic 선택 표시가 false로 되돌아오지 않는 결함 실제 DOM에 대응하는 대표 control 'case052-purpose-control'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 5758ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-52"></a> <details><summary>CASE-053 — CASE-053 UI group creation and invitation acceptance survive reload and revoked membership leaves the open group (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 두 사용자의 실제 그룹 생성/초대수락 뒤 권한 회수와 열린 화면 제거·서버 재진입 거절을 검사한다. 대표 control의 별도 경계 한계는 #9에 기록한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:04:33.331Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 feature-round-trip, journey-completion의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 feature-round-trip, journey-completion 완료를 대조했다. 이 CASE의 정리 resource 3개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 수정 확인: dashboard.group이 실제 표시된 뒤 해당 화면 내부의 알림 버튼을 선택한다. 화면 전환 직후 전역 visible 버튼을 집어 이전 화면 버튼을 기다리던 모호한 범위를 제거했다. 그룹 초대/수락/철회 단언은 보존되며 새 실행 대기다. 권한회수 전 현재 문서 attendance 초기응답의200/finished를먼저확인한다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: 준비된 owner/member ID 정확집합, 철회 후 멤버0과 SQLSTATE42501이 독립 oracle다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	CASE-053 UI group creation and invitation acceptance survive reload and revoked membership leaves the open group: 실제 완료한 필수 상황·목표 checkpoint는 feature-round-trip, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 목표: 가입 철회 후 서버에 멤버 행이 남는 권한 폐기 결함의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: 중복 멤버 없음, 알림소멸, reload 유지 후 열린 lounge/그룹목록 제거와 서버42501을 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	feature-round-trip, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	membership 제거 후 해당 사용자·그룹 RPC의 권한 거절을 빠뜨리는 SQL 결함을 정상→기존 목표 단언 실패→원본 복원 정상으로 확인했다. 실제 기대/관측값 불일치·정확한 최초 단언 위치·자동 재시도0·소유 자원 정리·SQL 정의/소유자/ACL 복원을 검증했다. 모든 가능한 결함을 증명하는 뜻은 아니다. 실제 SQL 주입·정확한 첫 예외·복원 readback은 원본 파일에 고정했고, 같은 후보의 공통 판정기 회귀가 미주입/생존/시간초과/다른 예외/정리 실패를 거절한 결과를 함께 대조했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 3개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 4820ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-53"></a> <details><summary>CASE-054 — CASE-054 composed catalog search and failed archive retry preserve historical facts and restore the exercise (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 로컬 IME 검색의 최종어·빈결과와 실제 archive 실패/재시도/복원 후 과거 원본 불변을 검사한다. 대표 control의 별도 경계 한계는 #9에 기록한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:04:38.290Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 feature-round-trip, journey-completion의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 feature-round-trip, journey-completion 완료를 대조했다. 이 CASE의 정리 resource 2개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 제어 확인: composition 이벤트와 화면 결과, 실제 archive 첫 요청 도착/오류, 상태변화·재진입으로 순서를 제어한다. 실제 사건 발생 여부의 현재 실행 판정은 #6 U와 분리한다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: 검색어 한글/존재하지않는검색어, active=false→true 및 작업 전 원본 ID/값 불변은 제품 계산 재호출이 아닌 입력·보존 계약이다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	CASE-054 composed catalog search and failed archive retry preserve historical facts and restore the exercise: 실제 완료한 필수 상황·목표 checkpoint는 feature-round-trip, journey-completion이다. 선언한 실패 declared-post-503-1:POST /rest/v1/rpc/set_own_custom_exercise_active의 실제 요청·시도 관측에서 missingAttempts/violations가 모두 비었다. 필수 복구 사건 observedCount=1와 누락/위반0도 확인했다. 목표: 종목 보관이 과거 운동 원본 세트 값을 바꾸는 금지 부작용의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: 빈 검색결과, 실패 후 재시도 가능, active 카탈로그 제외·관리 목록 유지, 과거 기록 전체 ID/값 보존과 reload/복원을 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	feature-round-trip, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 종목 보관이 과거 운동 원본 세트 값을 바꾸는 금지 부작용 SDK가 읽는 실제 HTTP 응답1건에 대응하는 대표 control 'case054-purpose-control'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. HTTP 응답 경계의 결함 검출이며 실제 DB 제약을 제거한 제품 결함 실험으로 확대하지 않는다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 6173ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-54"></a> <details><summary>CASE-055 — CASE-055 desktop Wodup upload runs the real job and a mixed duplicate batch cannot partially overwrite facts (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 실제 Wodup 업로드/Storage/Edge job의 최초 인입, 중복혼합 전체거절, 수정재시도와 원본 보존을 검사한다. 대표 control의 별도 경계 한계는 #9에 기록한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:04:44.572Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 feature-round-trip, journey-completion의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 feature-round-trip, journey-completion 완료를 대조했다. 이 CASE의 정리 resource 5개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 제어 확인: 실제 batch terminal 상태를 10초 poll로 관측하고 exact 실패 안내 뒤 readback·수정 업로드를 진행한다. 실제 사건 발생 여부의 현재 실행 판정은 #6 U와 분리한다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: sourceRow의 62.5kg×7, first/second title과 원본 fact ID/값 불변·정확 batch 상태를 독립 oracle로 삼는다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	CASE-055 desktop Wodup upload runs the real job and a mixed duplicate batch cannot partially overwrite facts: 실제 완료한 필수 상황·목표 checkpoint는 feature-round-trip, journey-completion이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 필수 복구 사건 observedCount=1와 누락/위반0도 확인했다. 목표: 중복 혼합 batch 실패가 기존 운동 일부를 바꾸는 원자성 결함의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: mixed duplicate 때 새 session0·기존 facts 불변, corrected batch 성공, 세 batch terminal 상태, 원본 storage 파일과 export를 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	feature-round-trip, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	중복이 섞인 Wodup 입력에서 기존 항목만 제외하고 신규 부분을 잘못 수락하는 SQL 결함을 정상→기존 목표 단언 실패→원본 복원 정상으로 확인했다. 실제 기대/관측값 불일치·정확한 최초 단언 위치·자동 재시도0·소유 자원 정리·SQL 정의/소유자/ACL 복원을 검증했다. 모든 가능한 결함을 증명하는 뜻은 아니다. 실제 SQL 주입·정확한 첫 예외·복원 readback은 원본 파일에 고정했고, 같은 후보의 공통 판정기 회귀가 미주입/생존/시간초과/다른 예외/정리 실패를 거절한 결과를 함께 대조했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 5개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 9284ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-55"></a> <details><summary>CASE-056 — Motra UI import atomic recovery and ordinary-user permission denial (U)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 실제 관리자 UI의 Motra 업로드·혼합 중복 원자 거절·수정 재시도와 일반 계정 UI 및 서버 RPC 거절의 두 필수 시나리오다. 응답 control과 선택된 로컬 SQL 제품 결함 실험의 계층을 구분한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	정적 준비 확인: localhost만 허용하고 명시한 로컬 자격으로 별도 Auth owner·UUID 입력을 생성한다. 고정 DATE는 업로드 원본 날짜이며 항상 과거라는 UI 분기에 의존하지 않는다. 실행 SHA·runId·실제 시작 시각·시간대 기록 경로가 있다. 소스1 소스2
3. 독립 실행	P	정적 독립성 확인: 각 시나리오가 자체 사용자와 인증을 준비하며 조회·삭제를 해당 owner/id로 한정한다. workers=1인 관리자 실행 범위이며 로컬 제품 결함은 전용 sandbox와 해당 owner로 한정하고 SQL 정의·owner·ACL을 복원한다. 실제 정리 성공 판정은 별도 실행 입력이다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 확인: UI 표시·업로드 응답·DB 값·권한 거절을 확인한다. reload 전에 실제 요청 terminal을 기다리며 response headers만으로 끝났다고 하지 않는다. 0ms browser task barrier는 임의의 안정 시간 추정이 아니며 준비의 정답은 도메인 단언이 담당한다. 소스1 소스2
5. 독립적인 정답	P	독립 정답 확인: 고정 입력 62.5×5/77.5×3, first/second 제목과 행 수, 기존 ID·값 불변, SQLSTATE42501 및 is_admin=false를 직접 단언한다. UI 결과끼리 비교하는 것만으로 합격시키지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	37aa 후보의 정상·복원 각 phase에서 관리자 혼합 중복 입력과 일반 계정 거절을 실제 관측했다. atomicity 정상 DB에는 기존 1개만 남고, permission 정상 RPC는42501을 반환했다. 두 하위 시나리오의 응답 control은 해당 소유 요청에 각각1회 적용됐으며 SQL mutant phase와 정상 결과를 구분한다. 소스1 소스2
7. 경계와 금지된 부작용	P	관련 경계 확인: 혼합 중복으로 새 session이 생기지 않음·기존 하위 ID/값 불변, 수정 파일만 성공, reload 후 원본 유지, 일반 계정 UI 탭0 및 server42501을 필수 단언한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	37aa 정상·복원 4개 phase의 필수 두 시나리오 8회에서 각각7/4 proof 완료, reporter problems=[], pending 오류0을 확인했다. 실제 Playwright 공통 회귀는 빈·삼킨·시간초과·미완료 proof를 거절했다. 의도한 mutant 실패를 정상 통과에 합산하지 않는다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	실제 로컬 SQL 결함 두 개를 적용해 정상→같은 목표 단언 실패→복원 정상 대조를 확인했다. Motra 중복을 건너뛰는 결함은 변경하지 않은 spec111의 원자 거절 단언에서 기대 행1개/실제2개로, 권한 해제 결함은 spec165의 기대42501/실제undefined로 실패했다. 각 native 최초 오류는 그 목표에 정확히 대응하며 준비·문법·timeout 실패가 아니다. SQL 정의 hash가 실제 변경되고 원래 정의·owner·ACL로 복원됐다. 같은37aa의 요청 terminal, 실패 정리, control 및 product-mutant 거짓 통과 거절 회귀가 함께 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	두 제품 결함 실험의 정상·목표 실패·복원 총12개 하위 실행 모두 소유 정리6개가 passed/settled, pending 요청0, 실제 요청 terminal 완료였다. SQL 정의·owner·ACL도 원복됐다. 같은37aa의 실제 본문 실패+정리 실패 분리, 자원 실패 뒤 나머지 정리 진행, SQL restore 실패 보존 회귀로 성공 경로만 확인한 한계를 보완했다. 소스1 소스2
11. 준비+본문 60초	P	37aa의 두 하위 시나리오를 포함한 정상·mutant·복원12실행의 준비+본문 native duration을 각각 읽었다. 최대2492ms로60초 이내이며 개별 준비를 제외한 bodyDuration만으로 판정하지 않았다. 정상 실행과 의도한 목표 실패는 별도 phase로 기록되어 있다. 소스1 소스2
12. 동작·조건 대기 10초	P	정적 상한: action/navigation/expect, SDK AbortSignal, control 각 단계, 개별 cleanup은10초다. 요청 대기는 하나의 deadline을 반복 루프 전체에서 재사용하며 SQL 준비/복원도각각공유10초deadline 안에서 statement_timeout과host deadline을 사용한다. 소스1 소스2
13. CASE 전체 재시도 0	P	자동 CASE retries=0이고 필수 reporter가 retry/repeat/expectedStatus override를 거절한다. normal/mutant/restored는 각각 구분된 실험 phase와 runId이며 실패를 재시도 성공으로 바꾸는 기능이 아니다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	U	관리자 필수 두 시나리오와 reporter는 로컬37aa에서 실제 통과하고 skip/retry/누락 거절도 확인했다. 그러나 docs hosted CI의 private backend artifact 소비에 필요한 BARBELIC_BACKEND_ARTIFACTS_READ_TOKEN이 미등록이며 이 필수 경로의 hosted 실행 증거가 없다. 로컬 통과로 이 공백을 P로 바꾸지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	37aa 모든 phase에 실제SHA·runId·CASE·attempt0·locale/timezone·proof와 요청 id/tab/document-generation/terminal이 남았다. 원자성·권한 mutant의 최초 native 오류는 기존 목표 파일/행·기대/실제값과 일치하고 cleanup 오류와 분리됐다. 같은37aa 공통 회귀에서 최초본문 오류 보존, 정리오류 별도기록, 응답/진단의 민감 payload 생략을 확인했다. 소스1 소스2

</details>

<a id="case-56"></a> <details><summary>CASE-057 — CASE-057 export failure creates no download and UI retry downloads exact owner facts and identities (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 내보내기 첫 실패의 다운로드0과 실제 JSON 재시도/재진입의 owner·세션/하위 ID/값 보존을 검사한다. 대표 control의 별도 경계 한계는 #9에 기록한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:04:54.117Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 feature-round-trip, journey-completion의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 feature-round-trip, journey-completion 완료를 대조했다. 이 CASE의 정리 resource 2개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 제어 확인: 실패 요청 도착→오류 dialog→download0, 사용자 export click의 실제 download event와 파일 stream 완료, reload 후 재다운로드를 관측한다. 실제 사건 발생 여부의 현재 실행 판정은 #6 U와 분리한다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: 별도 owner fixture IDs와 raw DB facts, app/version 상수, 실패 다운로드0/첫 성공1이 독립 oracle다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	CASE-057 export failure creates no download and UI retry downloads exact owner facts and identities: 실제 완료한 필수 상황·목표 checkpoint는 feature-round-trip, journey-completion이다. 선언한 실패 declared-get-400-1:GET /rest/v1/exercise_archetypes?select=id%2Cname_ko%2Cname_en%2Cprimary_part%2Cpattern%2Crep_exercise_id%2Cis_active%2Csort_order%2Ccreated_at%2Cupdated_at&is_active=eq.true&order=sort_order.asc%2Cname_ko.asc의 실제 요청·시도 관측에서 missingAttempts/violations가 모두 비었다. 필수 복구 사건 observedCount=2와 누락/위반0도 확인했다. 목표: 다운로드 export에 다른 사용자의 기록이 섞이는 소유권 누출의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: 부분/빈 파일 다운로드 없음, 다른 owner 전체 JSON 미포함, 원본 ID/값 보존·DB RLS 거절·reload export 동일성을 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	feature-round-trip, journey-completion 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: 다운로드 export에 다른 사용자의 기록이 섞이는 소유권 누출 SDK가 읽는 실제 HTTP 응답1건에 대응하는 대표 control 'case057-purpose-control'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. HTTP 응답 경계의 결함 검출이며 실제 DB 제약을 제거한 제품 결함 실험으로 확대하지 않는다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 7466ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-57"></a> <details><summary>CASE-058 — aborted IndexedDB enqueue preserves the input and a user retry saves once after recovery (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	정적 의미 확인: 실제 IDB enqueue transaction을 한 번 abort한 뒤 저장 실패·draft 보존 및 사용자 retry의 단일 저장·재진입을 검사한다. 대표 control의 별도 경계 한계는 #9에 기록한다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	최종93d의 local-1788983964771-26036에서 chromium/ko-KR/Asia/Seoul, 시작 2026-09-09T20:05:01.728Z, 상대 날짜 2026-09-10를 기록했다. 소스가 정의한 일회용 계정·입력과 시작 화면을 준비한 뒤 checkpoint-1, checkpoint-2, checkpoint-3의 실제 완료까지 확인했다. 고정 시계나 이전 CASE 데이터로 준비를 대신하지 않았다. 소스1 소스2
3. 독립 실행	P	최종 실행의 별도 browser shard/CASE 컨텍스트에서 자체 소유 계정·행을 준비하는 소스와 checkpoint-1, checkpoint-2, checkpoint-3 완료를 대조했다. 이 CASE의 정리 resource 2개가 모두 passed/settled이고 DB/Auth cleanup-readback 및 실제 페이지/리스너 종료가 확인됐다. 공용 backend를 쓰는 실행 순서를 전제하지 않으며 각 lane 격리 DB의 준비·첫시도 실행 증거와 연결한다. 소스1 소스2
4. 상태·사건에 따른 순서	P	정적 순서 제어 확인: 실제 transaction.abort 횟수1과 저장실패 화면을 확인한 뒤 원래 prototype을 복원하여 사용자 저장 버튼으로 진행한다. 실제 사건 발생 여부의 현재 실행 판정은 #6 U와 분리한다. 소스1 소스2
5. 독립적인 정답	P	정적 oracle 확인: 입력 title/완료한 exercise와 원래 operationId 불변, writes0→1/session0→1 및 60kg×5를 독립 비교한다. 앞뒤 보존 비교는 불변 요구의 oracle이며 단순 두 화면의 자기 일관성만을 통과 조건으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	aborted IndexedDB enqueue preserves the input and a user retry saves once after recovery: 실제 완료한 필수 상황·목표 checkpoint는 checkpoint-1, checkpoint-2, checkpoint-3이다. 주입 등록만을 발생 증거로 삼지 않고 해당 checkpoint 안의 입력·화면·저장·재진입 단언의 실제 종료를 소스와 연결했다. 필수 복구 사건 observedCount=1와 누락/위반0도 확인했다. 목표: enqueue 실패 뒤 durable draft의 운동 입력을 지우는 보존 결함의 대표 control 또한 정확히1회 적용됐다. 소스1 소스2
7. 경계와 금지된 부작용	P	정적 경계 확인: 실패 시 outbox0·전송0·서버0, 성공으로 오인하지 않는 버튼/alert, retry 단일 receipt/record·draft제거를 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	checkpoint-1, checkpoint-2, checkpoint-3 모두 실제 passed이고 단언 수가0보다 크다. 전체 필수 단언의 완료/중첩 poll을 판정한 quality.errors=[], diagnosticErrors=[], completion.missingSignals=[]이며 예상 밖 화면·브라우저·저장 오류0을 확인했다. 동일93d의 실제 Playwright bypass/빈·삼킨·미완료 단언 거절 회귀를 함께 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	목표: enqueue 실패 뒤 durable draft의 운동 입력을 지우는 보존 결함 소유 IndexedDB 행에 대응하는 대표 control 'case058-purpose-control'에서 같은 reader의 실제 normalActual=expected, negativeActual≠expected, restoredActual=expected이고 적용 횟수1/상태passed를 확인했다. 해당 관측 경계의 대표 결함 검출이며 모든 계층의 결함을 검사했다는 뜻은 아니다. 같은93d의 실제 DOM/IDB 및 요청 수명 회귀와 미적용·예외·시간초과·복수 적용을 거절하는 control 회귀가 통과했다. 소스1 소스2
10. 성공·실패의 자원 정리	P	해당 CASE의 resource 2개 정리 passed/settled, DB/Auth cleanup-readback, 관찰한 모든 page 실제close와 CDP observer disposal completed/잔여0, 각 소유 listener remove/readback 잔여0, RPC observer disposed/pending0와 모든 관측RPC settled를 확인했다. 먼저 해제된 observer의 closed=false와 실제페이지종료 증거를 구분했다. 이전 문서 pending은 숨기지 않고 실제close 증거와 구분한다. 같은93d의 준비·본문·정리실패/취소·reload·등록직후throw 경로 및 실제 PostgreSQL 취소 회귀를 함께 확인했다. 소스1 소스2
11. 준비+본문 60초	P	최초 시도0의 Playwright native duration은 6469ms로 개별 준비+본문을 포함해60초 이내다. 별도 사후 정리를 제외한 bodyDuration만으로 합격시키지 않았으며 현재 소스의60초 제한을 유지한다. 소스1 소스2
12. 동작·조건 대기 10초	P	최종 소스의 각 action/navigation/expect·SDK·조건 재조회는10초 이하인 하나의 deadline을 사용한다. 실제 실행에서 필수 단언/진단 오류0이며, 같은93d의 만료/취소·반복 stage 예산 갱신 거절과 실제 blocked PostgreSQL backend 종료/다른 연결 보존 검사를 확인했다. native 전체duration만으로 개별 대기 상한을 추정하지 않았다. 소스1 소스2
13. CASE 전체 재시도 0	P	정적 현재 설정 retries=0이고 해당 CASE 소스에 CASE 전체 재시도 override가 없다. 한 CASE 안의 제품 복구 재전송/10초 polling과 runner의 자동 CASE 재시도를 구분한다. 실제 실행 attempt는 별도 runtime U다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	해당93d 최초 시도0에서 모든 필수 checkpoint/control/정리 증거가 완료됐고 skip/flaky/quality 오류가 없다. 4 browser shard56개+viewport22개를 같은 run에서 대조한 필수 e2e-evidence gate와 현재 소스의 skip/only/시간상향/단언누락 거절, 실제 Playwright 우회 거절, 필수 DB 취소2개 실행을 확인했다. 이 실행은 browser+viewport 부분 단계이며 전체 CI 통과로 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	실제 진단1개에 최종SHA·CASE·runId·attempt0·project/locale/timezone·시각·정리단계와 요청/탭/문서세대, control의 기대·실제값 및 소유 미완료 작업 상태가 있다. 현재 정상 실행의 firstFailure.message/stack 및 cleanupFailure는 diagnosticValue의 명시적 undefined 표식이며 오류 내용이 없다. 관련 공통 실제 최초실패/teardown timeout 회귀는 두 오류를 별도 보존했다. 진단 가림 회귀도 확인해 자격과 URL 민감값을 결과에서 제외하는 범위를 검증했다. 소스1 소스2

</details>

<a id="case-58"></a> <details><summary>V0 compact 320x568 — V0 compact 320x568 (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	실제 입력·행동·단언으로 목적을 확정했다: V0의 명시된 viewport·DPR·touch 조건에서 home/calendar/volume/feed/profile 5개 화면의 가로 넘침, 컬럼 폭, 호스트 배경을 검사한다. 검증 계층: 실제 로그인 앱의 DOM rect·scrollWidth·computedStyle. 픽셀 완전일치나 기기 네이티브 렌더링 전체를 주장하지 않는다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	시작 입력의 소스 근거: 공유 준비에서 일회용 계정과 완료 운동 4건·통계 fixture를 만든다. 각 CASE는 새로운 context에서 지정 viewport/DPR/touch를 쓰며, 업무 날짜와 locale/timezone은 명시한다. 날짜는 명시된 geometry/feature fixture 입력이며 난수UUID는 계정·mutation 격리용이다. 실제 새 실행 환경 일치 증거는 별도 runtime 항목으로 남긴다. 소스1 소스2
3. 독립 실행	P	전용 일회용 계정과 CASE별 새 context/page를 사용한다. workers1에서만 이 공유 fixture를 실행하며 다른 CASE 결과를 입력으로 쓰지 않는다. DB cron scope는 명시 격리 sandbox를 확인하고 teardown에서 복원한다. 실제 성공/실패 정리 완료는 기준10에서 별도 U다. 소스1 소스2
4. 상태·사건에 따른 순서	P	상태·사건으로 순서 제어: 지정 context에서 실제 탭의 visible view와 레이아웃 안정 상태를 확인한 뒤 측정한다. 필요한 response/visible/배치정착을 기다리며 고정 sleep·networkidle만으로 준비를 판정하지 않는다. 단일 조건 대기는 lazyConditionWait와 viewportReadiness의 10초 경계로 제어한다. 개별 통계 준비는 해당 owner의 실제 세대를 읽어 단일10초 deadline으로 완료시키는 경로로 연결됐다. 응답 주입 CASE는 실제 현재 문서의 요청 ID와 주입 구간을 별도 기록한다. 소스1 소스2
5. 독립적인 정답	P	독립 기대값의 실제 근거: 독립 기기 표의 기대 폭 320px, document/screen 가로 넘침 0, 비투명 배경을 사용한다. 앱의 폭 계산 함수를 다시 호출하지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	320×568 compact 실제 context에서 home/calendar/volume/feed/profile를 각각 연 뒤 폭·넘침·배경을 측정했다. local-1788983964771-26036의 해당 CASE checkpoint 5개와 실제 단언 위치/종료를 원래 소스 조건에 대조했다. 실제 context/document와 정상 reader 값도 함께 확인했다. 소스1 소스2
7. 경계와 금지된 부작용	P	해당 목적의 경계·금지결과: 같은 viewport에서 5개 탭을 모두 열며 문서와 내부 screen 양쪽 넘침을 확인한다. 넓은 touch·가로 화면·pointer·desktop은 별도 정확한 title CASE들로 필수 목록에 연결된다. DB 저장·권한 부작용은 이 기하 CASE의 검증 범위가 아니다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	정본의 5개 필수 checkpoint가 정확히 한 번씩 완료됐고 그 안의 실제 단언 30개가 끝났다. 해당 CASE는 firstAttempt=true이며 missing/duplicate/swallowed/unfinished 오류가 없다. 실제 Playwright 우회·미완료 거절 및 성공 poll 내부 샘플 구분 회귀를 별도 연결했다. 단언 개수만으로 목적을 승인하지 않고 기준6의 실제 상황과 원래 단언 소스에 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	viewport-v0-column-width가 'V0 home'에서 실제 변경1회를 기록했다. 동일 reader/comparator의 정상 320 → 결함 352(불일치) → 복원 320(정상 재일치)를 확인했다. home의 실제 device width를 기대 폭+32px로 변경하고 동일 readViewportMetrics().column과 고정 표 기대값으로 불일치를 판정한다. home 폭 결함의 대표 증거이며 다른 4개 탭의 모든 CSS 결함에 대한 mutation 증거는 아니다. home 컬럼 폭의 DOM/CSS 경계 대표 결함만 대조한다. 현재 SHA의 실제 DOM/CSS mutation·복원 회귀와 무변경/예외/timeout 오인 거절 엔진 회귀를 연결했다. 이 판정은 해당 UI 경계 대표 결함이며 모든 단언 또는 제품 DB/권한/원자성 source mutant 탐지 범위를 주장하지 않는다. 소스1 소스2
10. 성공·실패의 자원 정리	P	이 CASE의 owned-cleanup이 completed=true이고 모든 context/control/route 자원이 settled/pass다. 실제 page close와 그 뒤 observer disposal/남은 owned listener0을 확인했다. 같은 CASE afterEach 또는 같은 spec의 공유 afterAll이 완료돼 계정·cron 정리 경로도 끝났다. 공유 afterAll은 마지막 CASE stream에 기록된 동일 공유fixture hook을 인용하며 다른 CASE의 본문을 근거로 쓰지 않았다. 실제 기본/수동 context의 본문 실패 경로 및 close/acquire 실패 보존 회귀도 연결했다. 종료 시 역사적 pending 요청은 pageClosed와 구별해 보존하며 정상 응답 완료로 바꾸지 않았다. 소스1 소스2
11. 준비+본문 60초	P	해당 native test의 effective timeout은60000ms이고 최초 시도 duration은4040ms로 개별 준비+본문 60초 한도 안에 끝났다. 공유 beforeAll과 teardown은 별도 hook 예산으로 구분했다. 동작별10초는 현재 소스 기준12 및 별도 bounded-wait 회귀로 확인하며 이 총시간만으로 대체하지 않는다. 소스1 소스2
12. 동작·조건 대기 10초	P	클릭·이동·expect 설정 최대10초, viewportReadiness의 폰트·유한 애니메이션·기하 안정화 한 poll, 수동 도착/완료 lazyConditionWait의 첫 await부터10초와 timer 취소를 확인했다. 지연 응답 route.fetch도10초이며 공유 beforeAll의 별도 예산과 CASE 개별 준비를 구분한다. 소스1 소스2
13. CASE 전체 재시도 0	P	config retries0이며 CASE/file override로전체CASE재시도를켜지않는다. reporter는result.retry!==0을거절한다.같은조건의한정poll/제품의사용자재조회는자동CASE재시도가아니다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정본 viewport22/117checkpoint/22control이 누락 없이 선택되고 각 required reporter와 통합 e2e-evidence 단계가 local-1788983964771-26036에서 pass했다. 이 CASE의 실제 retry0·빈 skip/fixme annotations·expectedStatus passed를 대조했고 재시도/예상실패/누락을 거절하는 집행 회귀도 확인했다. 이는 승인된 browser+viewport 부분 실행의 실제 필수 gate 증거이며 full CI·hosted 승격 완료로 확대 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	정확히1개 진단 attachment의 CASE title/정확SHA/run/attempt/project/locale/timezone/start/end를 해당 결과와 대조했다. 실제 CDP document/loader 세대, request/protocol ID·method/path/status/terminal, control 정상·주입·negative·복원 시각과 문서 연결, close 이후 listener 정리 기록을 확인했다. 보류 요청은 같은 실제 request/document와 phase로 연결됐다. 이 정상 실행의 firstFailure/cleanupFailure는 null이며 이를 실패 경로 증명으로 쓰지 않는다. 현재 SHA에서 실제 viewport reload/hold/first-failure, teardown 중단의 조기 진단 보존, 민감값 제거 회귀를 별도 연결했다. 소스1 소스2

</details>

<a id="case-59"></a> <details><summary>V1 phone 360x780 — V1 phone 360x780 (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	실제 입력·행동·단언으로 목적을 확정했다: V1의 명시된 viewport·DPR·touch 조건에서 home/calendar/volume/feed/profile 5개 화면의 가로 넘침, 컬럼 폭, 호스트 배경을 검사한다. 검증 계층: 실제 로그인 앱의 DOM rect·scrollWidth·computedStyle. 픽셀 완전일치나 기기 네이티브 렌더링 전체를 주장하지 않는다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	시작 입력의 소스 근거: 공유 준비에서 일회용 계정과 완료 운동 4건·통계 fixture를 만든다. 각 CASE는 새로운 context에서 지정 viewport/DPR/touch를 쓰며, 업무 날짜와 locale/timezone은 명시한다. 날짜는 명시된 geometry/feature fixture 입력이며 난수UUID는 계정·mutation 격리용이다. 실제 새 실행 환경 일치 증거는 별도 runtime 항목으로 남긴다. 소스1 소스2
3. 독립 실행	P	전용 일회용 계정과 CASE별 새 context/page를 사용한다. workers1에서만 이 공유 fixture를 실행하며 다른 CASE 결과를 입력으로 쓰지 않는다. DB cron scope는 명시 격리 sandbox를 확인하고 teardown에서 복원한다. 실제 성공/실패 정리 완료는 기준10에서 별도 U다. 소스1 소스2
4. 상태·사건에 따른 순서	P	상태·사건으로 순서 제어: 지정 context에서 실제 탭의 visible view와 레이아웃 안정 상태를 확인한 뒤 측정한다. 필요한 response/visible/배치정착을 기다리며 고정 sleep·networkidle만으로 준비를 판정하지 않는다. 단일 조건 대기는 lazyConditionWait와 viewportReadiness의 10초 경계로 제어한다. 개별 통계 준비는 해당 owner의 실제 세대를 읽어 단일10초 deadline으로 완료시키는 경로로 연결됐다. 응답 주입 CASE는 실제 현재 문서의 요청 ID와 주입 구간을 별도 기록한다. 소스1 소스2
5. 독립적인 정답	P	독립 기대값의 실제 근거: 독립 기기 표의 기대 폭 360px, document/screen 가로 넘침 0, 비투명 배경을 사용한다. 앱의 폭 계산 함수를 다시 호출하지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	360×780 phone 실제 context에서 5개 탭을 각각 연 뒤 폭·넘침·배경을 측정했다. local-1788983964771-26036의 해당 CASE checkpoint 5개와 실제 단언 위치/종료를 원래 소스 조건에 대조했다. 실제 context/document와 정상 reader 값도 함께 확인했다. 소스1 소스2
7. 경계와 금지된 부작용	P	해당 목적의 경계·금지결과: 같은 viewport에서 5개 탭을 모두 열며 문서와 내부 screen 양쪽 넘침을 확인한다. 넓은 touch·가로 화면·pointer·desktop은 별도 정확한 title CASE들로 필수 목록에 연결된다. DB 저장·권한 부작용은 이 기하 CASE의 검증 범위가 아니다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	정본의 5개 필수 checkpoint가 정확히 한 번씩 완료됐고 그 안의 실제 단언 30개가 끝났다. 해당 CASE는 firstAttempt=true이며 missing/duplicate/swallowed/unfinished 오류가 없다. 실제 Playwright 우회·미완료 거절 및 성공 poll 내부 샘플 구분 회귀를 별도 연결했다. 단언 개수만으로 목적을 승인하지 않고 기준6의 실제 상황과 원래 단언 소스에 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	viewport-v1-column-width가 'V1 home'에서 실제 변경1회를 기록했다. 동일 reader/comparator의 정상 360 → 결함 392(불일치) → 복원 360(정상 재일치)를 확인했다. home의 실제 device width를 기대 폭+32px로 변경하고 동일 readViewportMetrics().column과 고정 표 기대값으로 불일치를 판정한다. home 폭 결함의 대표 증거이며 다른 4개 탭의 모든 CSS 결함에 대한 mutation 증거는 아니다. home 컬럼 폭의 DOM/CSS 경계 대표 결함만 대조한다. 현재 SHA의 실제 DOM/CSS mutation·복원 회귀와 무변경/예외/timeout 오인 거절 엔진 회귀를 연결했다. 이 판정은 해당 UI 경계 대표 결함이며 모든 단언 또는 제품 DB/권한/원자성 source mutant 탐지 범위를 주장하지 않는다. 소스1 소스2
10. 성공·실패의 자원 정리	P	이 CASE의 owned-cleanup이 completed=true이고 모든 context/control/route 자원이 settled/pass다. 실제 page close와 그 뒤 observer disposal/남은 owned listener0을 확인했다. 같은 CASE afterEach 또는 같은 spec의 공유 afterAll이 완료돼 계정·cron 정리 경로도 끝났다. 공유 afterAll은 마지막 CASE stream에 기록된 동일 공유fixture hook을 인용하며 다른 CASE의 본문을 근거로 쓰지 않았다. 실제 기본/수동 context의 본문 실패 경로 및 close/acquire 실패 보존 회귀도 연결했다. 종료 시 역사적 pending 요청은 pageClosed와 구별해 보존하며 정상 응답 완료로 바꾸지 않았다. 소스1 소스2
11. 준비+본문 60초	P	해당 native test의 effective timeout은60000ms이고 최초 시도 duration은4439ms로 개별 준비+본문 60초 한도 안에 끝났다. 공유 beforeAll과 teardown은 별도 hook 예산으로 구분했다. 동작별10초는 현재 소스 기준12 및 별도 bounded-wait 회귀로 확인하며 이 총시간만으로 대체하지 않는다. 소스1 소스2
12. 동작·조건 대기 10초	P	클릭·이동·expect 설정 최대10초, viewportReadiness의 폰트·유한 애니메이션·기하 안정화 한 poll, 수동 도착/완료 lazyConditionWait의 첫 await부터10초와 timer 취소를 확인했다. 지연 응답 route.fetch도10초이며 공유 beforeAll의 별도 예산과 CASE 개별 준비를 구분한다. 소스1 소스2
13. CASE 전체 재시도 0	P	config retries0이며 CASE/file override로전체CASE재시도를켜지않는다. reporter는result.retry!==0을거절한다.같은조건의한정poll/제품의사용자재조회는자동CASE재시도가아니다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정본 viewport22/117checkpoint/22control이 누락 없이 선택되고 각 required reporter와 통합 e2e-evidence 단계가 local-1788983964771-26036에서 pass했다. 이 CASE의 실제 retry0·빈 skip/fixme annotations·expectedStatus passed를 대조했고 재시도/예상실패/누락을 거절하는 집행 회귀도 확인했다. 이는 승인된 browser+viewport 부분 실행의 실제 필수 gate 증거이며 full CI·hosted 승격 완료로 확대 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	정확히1개 진단 attachment의 CASE title/정확SHA/run/attempt/project/locale/timezone/start/end를 해당 결과와 대조했다. 실제 CDP document/loader 세대, request/protocol ID·method/path/status/terminal, control 정상·주입·negative·복원 시각과 문서 연결, close 이후 listener 정리 기록을 확인했다. 보류 요청은 같은 실제 request/document와 phase로 연결됐다. 이 정상 실행의 firstFailure/cleanupFailure는 null이며 이를 실패 경로 증명으로 쓰지 않는다. 현재 SHA에서 실제 viewport reload/hold/first-failure, teardown 중단의 조기 진단 보존, 민감값 제거 회귀를 별도 연결했다. 소스1 소스2

</details>

<a id="case-60"></a> <details><summary>V2 phone 375x667 — V2 phone 375x667 (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	실제 입력·행동·단언으로 목적을 확정했다: V2의 명시된 viewport·DPR·touch 조건에서 home/calendar/volume/feed/profile 5개 화면의 가로 넘침, 컬럼 폭, 호스트 배경을 검사한다. 검증 계층: 실제 로그인 앱의 DOM rect·scrollWidth·computedStyle. 픽셀 완전일치나 기기 네이티브 렌더링 전체를 주장하지 않는다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	시작 입력의 소스 근거: 공유 준비에서 일회용 계정과 완료 운동 4건·통계 fixture를 만든다. 각 CASE는 새로운 context에서 지정 viewport/DPR/touch를 쓰며, 업무 날짜와 locale/timezone은 명시한다. 날짜는 명시된 geometry/feature fixture 입력이며 난수UUID는 계정·mutation 격리용이다. 실제 새 실행 환경 일치 증거는 별도 runtime 항목으로 남긴다. 소스1 소스2
3. 독립 실행	P	전용 일회용 계정과 CASE별 새 context/page를 사용한다. workers1에서만 이 공유 fixture를 실행하며 다른 CASE 결과를 입력으로 쓰지 않는다. DB cron scope는 명시 격리 sandbox를 확인하고 teardown에서 복원한다. 실제 성공/실패 정리 완료는 기준10에서 별도 U다. 소스1 소스2
4. 상태·사건에 따른 순서	P	상태·사건으로 순서 제어: 지정 context에서 실제 탭의 visible view와 레이아웃 안정 상태를 확인한 뒤 측정한다. 필요한 response/visible/배치정착을 기다리며 고정 sleep·networkidle만으로 준비를 판정하지 않는다. 단일 조건 대기는 lazyConditionWait와 viewportReadiness의 10초 경계로 제어한다. 개별 통계 준비는 해당 owner의 실제 세대를 읽어 단일10초 deadline으로 완료시키는 경로로 연결됐다. 응답 주입 CASE는 실제 현재 문서의 요청 ID와 주입 구간을 별도 기록한다. 소스1 소스2
5. 독립적인 정답	P	독립 기대값의 실제 근거: 독립 기기 표의 기대 폭 375px, document/screen 가로 넘침 0, 비투명 배경을 사용한다. 앱의 폭 계산 함수를 다시 호출하지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	375×667 phone 실제 context에서 5개 탭을 각각 연 뒤 폭·넘침·배경을 측정했다. local-1788983964771-26036의 해당 CASE checkpoint 5개와 실제 단언 위치/종료를 원래 소스 조건에 대조했다. 실제 context/document와 정상 reader 값도 함께 확인했다. 소스1 소스2
7. 경계와 금지된 부작용	P	해당 목적의 경계·금지결과: 같은 viewport에서 5개 탭을 모두 열며 문서와 내부 screen 양쪽 넘침을 확인한다. 넓은 touch·가로 화면·pointer·desktop은 별도 정확한 title CASE들로 필수 목록에 연결된다. DB 저장·권한 부작용은 이 기하 CASE의 검증 범위가 아니다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	정본의 5개 필수 checkpoint가 정확히 한 번씩 완료됐고 그 안의 실제 단언 30개가 끝났다. 해당 CASE는 firstAttempt=true이며 missing/duplicate/swallowed/unfinished 오류가 없다. 실제 Playwright 우회·미완료 거절 및 성공 poll 내부 샘플 구분 회귀를 별도 연결했다. 단언 개수만으로 목적을 승인하지 않고 기준6의 실제 상황과 원래 단언 소스에 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	viewport-v2-column-width가 'V2 home'에서 실제 변경1회를 기록했다. 동일 reader/comparator의 정상 375 → 결함 407(불일치) → 복원 375(정상 재일치)를 확인했다. home의 실제 device width를 기대 폭+32px로 변경하고 동일 readViewportMetrics().column과 고정 표 기대값으로 불일치를 판정한다. home 폭 결함의 대표 증거이며 다른 4개 탭의 모든 CSS 결함에 대한 mutation 증거는 아니다. home 컬럼 폭의 DOM/CSS 경계 대표 결함만 대조한다. 현재 SHA의 실제 DOM/CSS mutation·복원 회귀와 무변경/예외/timeout 오인 거절 엔진 회귀를 연결했다. 이 판정은 해당 UI 경계 대표 결함이며 모든 단언 또는 제품 DB/권한/원자성 source mutant 탐지 범위를 주장하지 않는다. 소스1 소스2
10. 성공·실패의 자원 정리	P	이 CASE의 owned-cleanup이 completed=true이고 모든 context/control/route 자원이 settled/pass다. 실제 page close와 그 뒤 observer disposal/남은 owned listener0을 확인했다. 같은 CASE afterEach 또는 같은 spec의 공유 afterAll이 완료돼 계정·cron 정리 경로도 끝났다. 공유 afterAll은 마지막 CASE stream에 기록된 동일 공유fixture hook을 인용하며 다른 CASE의 본문을 근거로 쓰지 않았다. 실제 기본/수동 context의 본문 실패 경로 및 close/acquire 실패 보존 회귀도 연결했다. 종료 시 역사적 pending 요청은 pageClosed와 구별해 보존하며 정상 응답 완료로 바꾸지 않았다. 소스1 소스2
11. 준비+본문 60초	P	해당 native test의 effective timeout은60000ms이고 최초 시도 duration은4077ms로 개별 준비+본문 60초 한도 안에 끝났다. 공유 beforeAll과 teardown은 별도 hook 예산으로 구분했다. 동작별10초는 현재 소스 기준12 및 별도 bounded-wait 회귀로 확인하며 이 총시간만으로 대체하지 않는다. 소스1 소스2
12. 동작·조건 대기 10초	P	클릭·이동·expect 설정 최대10초, viewportReadiness의 폰트·유한 애니메이션·기하 안정화 한 poll, 수동 도착/완료 lazyConditionWait의 첫 await부터10초와 timer 취소를 확인했다. 지연 응답 route.fetch도10초이며 공유 beforeAll의 별도 예산과 CASE 개별 준비를 구분한다. 소스1 소스2
13. CASE 전체 재시도 0	P	config retries0이며 CASE/file override로전체CASE재시도를켜지않는다. reporter는result.retry!==0을거절한다.같은조건의한정poll/제품의사용자재조회는자동CASE재시도가아니다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정본 viewport22/117checkpoint/22control이 누락 없이 선택되고 각 required reporter와 통합 e2e-evidence 단계가 local-1788983964771-26036에서 pass했다. 이 CASE의 실제 retry0·빈 skip/fixme annotations·expectedStatus passed를 대조했고 재시도/예상실패/누락을 거절하는 집행 회귀도 확인했다. 이는 승인된 browser+viewport 부분 실행의 실제 필수 gate 증거이며 full CI·hosted 승격 완료로 확대 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	정확히1개 진단 attachment의 CASE title/정확SHA/run/attempt/project/locale/timezone/start/end를 해당 결과와 대조했다. 실제 CDP document/loader 세대, request/protocol ID·method/path/status/terminal, control 정상·주입·negative·복원 시각과 문서 연결, close 이후 listener 정리 기록을 확인했다. 보류 요청은 같은 실제 request/document와 phase로 연결됐다. 이 정상 실행의 firstFailure/cleanupFailure는 null이며 이를 실패 경로 증명으로 쓰지 않는다. 현재 SHA에서 실제 viewport reload/hold/first-failure, teardown 중단의 조기 진단 보존, 민감값 제거 회귀를 별도 연결했다. 소스1 소스2

</details>

<a id="case-61"></a> <details><summary>V3 phone 390x844 — V3 phone 390x844 (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	실제 입력·행동·단언으로 목적을 확정했다: V3의 명시된 viewport·DPR·touch 조건에서 home/calendar/volume/feed/profile 5개 화면의 가로 넘침, 컬럼 폭, 호스트 배경을 검사한다. 검증 계층: 실제 로그인 앱의 DOM rect·scrollWidth·computedStyle. 픽셀 완전일치나 기기 네이티브 렌더링 전체를 주장하지 않는다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	시작 입력의 소스 근거: 공유 준비에서 일회용 계정과 완료 운동 4건·통계 fixture를 만든다. 각 CASE는 새로운 context에서 지정 viewport/DPR/touch를 쓰며, 업무 날짜와 locale/timezone은 명시한다. 날짜는 명시된 geometry/feature fixture 입력이며 난수UUID는 계정·mutation 격리용이다. 실제 새 실행 환경 일치 증거는 별도 runtime 항목으로 남긴다. 소스1 소스2
3. 독립 실행	P	전용 일회용 계정과 CASE별 새 context/page를 사용한다. workers1에서만 이 공유 fixture를 실행하며 다른 CASE 결과를 입력으로 쓰지 않는다. DB cron scope는 명시 격리 sandbox를 확인하고 teardown에서 복원한다. 실제 성공/실패 정리 완료는 기준10에서 별도 U다. 소스1 소스2
4. 상태·사건에 따른 순서	P	상태·사건으로 순서 제어: 지정 context에서 실제 탭의 visible view와 레이아웃 안정 상태를 확인한 뒤 측정한다. 필요한 response/visible/배치정착을 기다리며 고정 sleep·networkidle만으로 준비를 판정하지 않는다. 단일 조건 대기는 lazyConditionWait와 viewportReadiness의 10초 경계로 제어한다. 개별 통계 준비는 해당 owner의 실제 세대를 읽어 단일10초 deadline으로 완료시키는 경로로 연결됐다. 응답 주입 CASE는 실제 현재 문서의 요청 ID와 주입 구간을 별도 기록한다. 소스1 소스2
5. 독립적인 정답	P	독립 기대값의 실제 근거: 독립 기기 표의 기대 폭 390px, document/screen 가로 넘침 0, 비투명 배경을 사용한다. 앱의 폭 계산 함수를 다시 호출하지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	390×844 phone 실제 context에서 5개 탭을 각각 연 뒤 폭·넘침·배경을 측정했다. local-1788983964771-26036의 해당 CASE checkpoint 5개와 실제 단언 위치/종료를 원래 소스 조건에 대조했다. 실제 context/document와 정상 reader 값도 함께 확인했다. 소스1 소스2
7. 경계와 금지된 부작용	P	해당 목적의 경계·금지결과: 같은 viewport에서 5개 탭을 모두 열며 문서와 내부 screen 양쪽 넘침을 확인한다. 넓은 touch·가로 화면·pointer·desktop은 별도 정확한 title CASE들로 필수 목록에 연결된다. DB 저장·권한 부작용은 이 기하 CASE의 검증 범위가 아니다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	정본의 5개 필수 checkpoint가 정확히 한 번씩 완료됐고 그 안의 실제 단언 30개가 끝났다. 해당 CASE는 firstAttempt=true이며 missing/duplicate/swallowed/unfinished 오류가 없다. 실제 Playwright 우회·미완료 거절 및 성공 poll 내부 샘플 구분 회귀를 별도 연결했다. 단언 개수만으로 목적을 승인하지 않고 기준6의 실제 상황과 원래 단언 소스에 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	viewport-v3-column-width가 'V3 home'에서 실제 변경1회를 기록했다. 동일 reader/comparator의 정상 390 → 결함 422(불일치) → 복원 390(정상 재일치)를 확인했다. home의 실제 device width를 기대 폭+32px로 변경하고 동일 readViewportMetrics().column과 고정 표 기대값으로 불일치를 판정한다. home 폭 결함의 대표 증거이며 다른 4개 탭의 모든 CSS 결함에 대한 mutation 증거는 아니다. home 컬럼 폭의 DOM/CSS 경계 대표 결함만 대조한다. 현재 SHA의 실제 DOM/CSS mutation·복원 회귀와 무변경/예외/timeout 오인 거절 엔진 회귀를 연결했다. 이 판정은 해당 UI 경계 대표 결함이며 모든 단언 또는 제품 DB/권한/원자성 source mutant 탐지 범위를 주장하지 않는다. 소스1 소스2
10. 성공·실패의 자원 정리	P	이 CASE의 owned-cleanup이 completed=true이고 모든 context/control/route 자원이 settled/pass다. 실제 page close와 그 뒤 observer disposal/남은 owned listener0을 확인했다. 같은 CASE afterEach 또는 같은 spec의 공유 afterAll이 완료돼 계정·cron 정리 경로도 끝났다. 공유 afterAll은 마지막 CASE stream에 기록된 동일 공유fixture hook을 인용하며 다른 CASE의 본문을 근거로 쓰지 않았다. 실제 기본/수동 context의 본문 실패 경로 및 close/acquire 실패 보존 회귀도 연결했다. 종료 시 역사적 pending 요청은 pageClosed와 구별해 보존하며 정상 응답 완료로 바꾸지 않았다. 소스1 소스2
11. 준비+본문 60초	P	해당 native test의 effective timeout은60000ms이고 최초 시도 duration은4553ms로 개별 준비+본문 60초 한도 안에 끝났다. 공유 beforeAll과 teardown은 별도 hook 예산으로 구분했다. 동작별10초는 현재 소스 기준12 및 별도 bounded-wait 회귀로 확인하며 이 총시간만으로 대체하지 않는다. 소스1 소스2
12. 동작·조건 대기 10초	P	클릭·이동·expect 설정 최대10초, viewportReadiness의 폰트·유한 애니메이션·기하 안정화 한 poll, 수동 도착/완료 lazyConditionWait의 첫 await부터10초와 timer 취소를 확인했다. 지연 응답 route.fetch도10초이며 공유 beforeAll의 별도 예산과 CASE 개별 준비를 구분한다. 소스1 소스2
13. CASE 전체 재시도 0	P	config retries0이며 CASE/file override로전체CASE재시도를켜지않는다. reporter는result.retry!==0을거절한다.같은조건의한정poll/제품의사용자재조회는자동CASE재시도가아니다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정본 viewport22/117checkpoint/22control이 누락 없이 선택되고 각 required reporter와 통합 e2e-evidence 단계가 local-1788983964771-26036에서 pass했다. 이 CASE의 실제 retry0·빈 skip/fixme annotations·expectedStatus passed를 대조했고 재시도/예상실패/누락을 거절하는 집행 회귀도 확인했다. 이는 승인된 browser+viewport 부분 실행의 실제 필수 gate 증거이며 full CI·hosted 승격 완료로 확대 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	정확히1개 진단 attachment의 CASE title/정확SHA/run/attempt/project/locale/timezone/start/end를 해당 결과와 대조했다. 실제 CDP document/loader 세대, request/protocol ID·method/path/status/terminal, control 정상·주입·negative·복원 시각과 문서 연결, close 이후 listener 정리 기록을 확인했다. 보류 요청은 같은 실제 request/document와 phase로 연결됐다. 이 정상 실행의 firstFailure/cleanupFailure는 null이며 이를 실패 경로 증명으로 쓰지 않는다. 현재 SHA에서 실제 viewport reload/hold/first-failure, teardown 중단의 조기 진단 보존, 민감값 제거 회귀를 별도 연결했다. 소스1 소스2

</details>

<a id="case-62"></a> <details><summary>V5 phone 440x956 — V5 phone 440x956 (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	실제 입력·행동·단언으로 목적을 확정했다: V5의 명시된 viewport·DPR·touch 조건에서 home/calendar/volume/feed/profile 5개 화면의 가로 넘침, 컬럼 폭, 호스트 배경을 검사한다. 검증 계층: 실제 로그인 앱의 DOM rect·scrollWidth·computedStyle. 픽셀 완전일치나 기기 네이티브 렌더링 전체를 주장하지 않는다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	시작 입력의 소스 근거: 공유 준비에서 일회용 계정과 완료 운동 4건·통계 fixture를 만든다. 각 CASE는 새로운 context에서 지정 viewport/DPR/touch를 쓰며, 업무 날짜와 locale/timezone은 명시한다. 날짜는 명시된 geometry/feature fixture 입력이며 난수UUID는 계정·mutation 격리용이다. 실제 새 실행 환경 일치 증거는 별도 runtime 항목으로 남긴다. 소스1 소스2
3. 독립 실행	P	전용 일회용 계정과 CASE별 새 context/page를 사용한다. workers1에서만 이 공유 fixture를 실행하며 다른 CASE 결과를 입력으로 쓰지 않는다. DB cron scope는 명시 격리 sandbox를 확인하고 teardown에서 복원한다. 실제 성공/실패 정리 완료는 기준10에서 별도 U다. 소스1 소스2
4. 상태·사건에 따른 순서	P	상태·사건으로 순서 제어: 지정 context에서 실제 탭의 visible view와 레이아웃 안정 상태를 확인한 뒤 측정한다. 필요한 response/visible/배치정착을 기다리며 고정 sleep·networkidle만으로 준비를 판정하지 않는다. 단일 조건 대기는 lazyConditionWait와 viewportReadiness의 10초 경계로 제어한다. 개별 통계 준비는 해당 owner의 실제 세대를 읽어 단일10초 deadline으로 완료시키는 경로로 연결됐다. 응답 주입 CASE는 실제 현재 문서의 요청 ID와 주입 구간을 별도 기록한다. 소스1 소스2
5. 독립적인 정답	P	독립 기대값의 실제 근거: 독립 기기 표의 기대 폭 440px, document/screen 가로 넘침 0, 비투명 배경을 사용한다. 앱의 폭 계산 함수를 다시 호출하지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	440×956 phone 실제 context에서 5개 탭을 각각 연 뒤 폭·넘침·배경을 측정했다. local-1788983964771-26036의 해당 CASE checkpoint 5개와 실제 단언 위치/종료를 원래 소스 조건에 대조했다. 실제 context/document와 정상 reader 값도 함께 확인했다. 소스1 소스2
7. 경계와 금지된 부작용	P	해당 목적의 경계·금지결과: 같은 viewport에서 5개 탭을 모두 열며 문서와 내부 screen 양쪽 넘침을 확인한다. 넓은 touch·가로 화면·pointer·desktop은 별도 정확한 title CASE들로 필수 목록에 연결된다. DB 저장·권한 부작용은 이 기하 CASE의 검증 범위가 아니다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	정본의 5개 필수 checkpoint가 정확히 한 번씩 완료됐고 그 안의 실제 단언 30개가 끝났다. 해당 CASE는 firstAttempt=true이며 missing/duplicate/swallowed/unfinished 오류가 없다. 실제 Playwright 우회·미완료 거절 및 성공 poll 내부 샘플 구분 회귀를 별도 연결했다. 단언 개수만으로 목적을 승인하지 않고 기준6의 실제 상황과 원래 단언 소스에 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	viewport-v5-column-width가 'V5 home'에서 실제 변경1회를 기록했다. 동일 reader/comparator의 정상 440 → 결함 472(불일치) → 복원 440(정상 재일치)를 확인했다. home의 실제 device width를 기대 폭+32px로 변경하고 동일 readViewportMetrics().column과 고정 표 기대값으로 불일치를 판정한다. home 폭 결함의 대표 증거이며 다른 4개 탭의 모든 CSS 결함에 대한 mutation 증거는 아니다. home 컬럼 폭의 DOM/CSS 경계 대표 결함만 대조한다. 현재 SHA의 실제 DOM/CSS mutation·복원 회귀와 무변경/예외/timeout 오인 거절 엔진 회귀를 연결했다. 이 판정은 해당 UI 경계 대표 결함이며 모든 단언 또는 제품 DB/권한/원자성 source mutant 탐지 범위를 주장하지 않는다. 소스1 소스2
10. 성공·실패의 자원 정리	P	이 CASE의 owned-cleanup이 completed=true이고 모든 context/control/route 자원이 settled/pass다. 실제 page close와 그 뒤 observer disposal/남은 owned listener0을 확인했다. 같은 CASE afterEach 또는 같은 spec의 공유 afterAll이 완료돼 계정·cron 정리 경로도 끝났다. 공유 afterAll은 마지막 CASE stream에 기록된 동일 공유fixture hook을 인용하며 다른 CASE의 본문을 근거로 쓰지 않았다. 실제 기본/수동 context의 본문 실패 경로 및 close/acquire 실패 보존 회귀도 연결했다. 종료 시 역사적 pending 요청은 pageClosed와 구별해 보존하며 정상 응답 완료로 바꾸지 않았다. 소스1 소스2
11. 준비+본문 60초	P	해당 native test의 effective timeout은60000ms이고 최초 시도 duration은4519ms로 개별 준비+본문 60초 한도 안에 끝났다. 공유 beforeAll과 teardown은 별도 hook 예산으로 구분했다. 동작별10초는 현재 소스 기준12 및 별도 bounded-wait 회귀로 확인하며 이 총시간만으로 대체하지 않는다. 소스1 소스2
12. 동작·조건 대기 10초	P	클릭·이동·expect 설정 최대10초, viewportReadiness의 폰트·유한 애니메이션·기하 안정화 한 poll, 수동 도착/완료 lazyConditionWait의 첫 await부터10초와 timer 취소를 확인했다. 지연 응답 route.fetch도10초이며 공유 beforeAll의 별도 예산과 CASE 개별 준비를 구분한다. 소스1 소스2
13. CASE 전체 재시도 0	P	config retries0이며 CASE/file override로전체CASE재시도를켜지않는다. reporter는result.retry!==0을거절한다.같은조건의한정poll/제품의사용자재조회는자동CASE재시도가아니다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정본 viewport22/117checkpoint/22control이 누락 없이 선택되고 각 required reporter와 통합 e2e-evidence 단계가 local-1788983964771-26036에서 pass했다. 이 CASE의 실제 retry0·빈 skip/fixme annotations·expectedStatus passed를 대조했고 재시도/예상실패/누락을 거절하는 집행 회귀도 확인했다. 이는 승인된 browser+viewport 부분 실행의 실제 필수 gate 증거이며 full CI·hosted 승격 완료로 확대 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	정확히1개 진단 attachment의 CASE title/정확SHA/run/attempt/project/locale/timezone/start/end를 해당 결과와 대조했다. 실제 CDP document/loader 세대, request/protocol ID·method/path/status/terminal, control 정상·주입·negative·복원 시각과 문서 연결, close 이후 listener 정리 기록을 확인했다. 보류 요청은 같은 실제 request/document와 phase로 연결됐다. 이 정상 실행의 firstFailure/cleanupFailure는 null이며 이를 실패 경로 증명으로 쓰지 않는다. 현재 SHA에서 실제 viewport reload/hold/first-failure, teardown 중단의 조기 진단 보존, 민감값 제거 회귀를 별도 연결했다. 소스1 소스2

</details>

<a id="case-63"></a> <details><summary>V6 wide-touch 820x1180 — V6 wide-touch 820x1180 (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	실제 입력·행동·단언으로 목적을 확정했다: V6의 명시된 viewport·DPR·touch 조건에서 home/calendar/volume/feed/profile 5개 화면의 가로 넘침, 컬럼 폭, 호스트 배경을 검사한다. 검증 계층: 실제 로그인 앱의 DOM rect·scrollWidth·computedStyle. 픽셀 완전일치나 기기 네이티브 렌더링 전체를 주장하지 않는다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	시작 입력의 소스 근거: 공유 준비에서 일회용 계정과 완료 운동 4건·통계 fixture를 만든다. 각 CASE는 새로운 context에서 지정 viewport/DPR/touch를 쓰며, 업무 날짜와 locale/timezone은 명시한다. 날짜는 명시된 geometry/feature fixture 입력이며 난수UUID는 계정·mutation 격리용이다. 실제 새 실행 환경 일치 증거는 별도 runtime 항목으로 남긴다. 소스1 소스2
3. 독립 실행	P	전용 일회용 계정과 CASE별 새 context/page를 사용한다. workers1에서만 이 공유 fixture를 실행하며 다른 CASE 결과를 입력으로 쓰지 않는다. DB cron scope는 명시 격리 sandbox를 확인하고 teardown에서 복원한다. 실제 성공/실패 정리 완료는 기준10에서 별도 U다. 소스1 소스2
4. 상태·사건에 따른 순서	P	상태·사건으로 순서 제어: 지정 context에서 실제 탭의 visible view와 레이아웃 안정 상태를 확인한 뒤 측정한다. 필요한 response/visible/배치정착을 기다리며 고정 sleep·networkidle만으로 준비를 판정하지 않는다. 단일 조건 대기는 lazyConditionWait와 viewportReadiness의 10초 경계로 제어한다. 개별 통계 준비는 해당 owner의 실제 세대를 읽어 단일10초 deadline으로 완료시키는 경로로 연결됐다. 응답 주입 CASE는 실제 현재 문서의 요청 ID와 주입 구간을 별도 기록한다. 소스1 소스2
5. 독립적인 정답	P	독립 기대값의 실제 근거: 독립 기기 표의 기대 폭 600px, document/screen 가로 넘침 0, 비투명 배경을 사용한다. 앱의 폭 계산 함수를 다시 호출하지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	820×1180 wide-touch 실제 context에서 5개 탭과 고정 600px 컬럼을 측정했다. local-1788983964771-26036의 해당 CASE checkpoint 5개와 실제 단언 위치/종료를 원래 소스 조건에 대조했다. 실제 context/document와 정상 reader 값도 함께 확인했다. 소스1 소스2
7. 경계와 금지된 부작용	P	해당 목적의 경계·금지결과: 같은 viewport에서 5개 탭을 모두 열며 문서와 내부 screen 양쪽 넘침을 확인한다. 넓은 touch·가로 화면·pointer·desktop은 별도 정확한 title CASE들로 필수 목록에 연결된다. DB 저장·권한 부작용은 이 기하 CASE의 검증 범위가 아니다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	정본의 5개 필수 checkpoint가 정확히 한 번씩 완료됐고 그 안의 실제 단언 30개가 끝났다. 해당 CASE는 firstAttempt=true이며 missing/duplicate/swallowed/unfinished 오류가 없다. 실제 Playwright 우회·미완료 거절 및 성공 poll 내부 샘플 구분 회귀를 별도 연결했다. 단언 개수만으로 목적을 승인하지 않고 기준6의 실제 상황과 원래 단언 소스에 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	viewport-v6-column-width가 'V6 home'에서 실제 변경1회를 기록했다. 동일 reader/comparator의 정상 600 → 결함 632(불일치) → 복원 600(정상 재일치)를 확인했다. home의 실제 device width를 기대 폭+32px로 변경하고 동일 readViewportMetrics().column과 고정 표 기대값으로 불일치를 판정한다. home 폭 결함의 대표 증거이며 다른 4개 탭의 모든 CSS 결함에 대한 mutation 증거는 아니다. home 컬럼 폭의 DOM/CSS 경계 대표 결함만 대조한다. 현재 SHA의 실제 DOM/CSS mutation·복원 회귀와 무변경/예외/timeout 오인 거절 엔진 회귀를 연결했다. 이 판정은 해당 UI 경계 대표 결함이며 모든 단언 또는 제품 DB/권한/원자성 source mutant 탐지 범위를 주장하지 않는다. 소스1 소스2
10. 성공·실패의 자원 정리	P	이 CASE의 owned-cleanup이 completed=true이고 모든 context/control/route 자원이 settled/pass다. 실제 page close와 그 뒤 observer disposal/남은 owned listener0을 확인했다. 같은 CASE afterEach 또는 같은 spec의 공유 afterAll이 완료돼 계정·cron 정리 경로도 끝났다. 공유 afterAll은 마지막 CASE stream에 기록된 동일 공유fixture hook을 인용하며 다른 CASE의 본문을 근거로 쓰지 않았다. 실제 기본/수동 context의 본문 실패 경로 및 close/acquire 실패 보존 회귀도 연결했다. 종료 시 역사적 pending 요청은 pageClosed와 구별해 보존하며 정상 응답 완료로 바꾸지 않았다. 소스1 소스2
11. 준비+본문 60초	P	해당 native test의 effective timeout은60000ms이고 최초 시도 duration은4084ms로 개별 준비+본문 60초 한도 안에 끝났다. 공유 beforeAll과 teardown은 별도 hook 예산으로 구분했다. 동작별10초는 현재 소스 기준12 및 별도 bounded-wait 회귀로 확인하며 이 총시간만으로 대체하지 않는다. 소스1 소스2
12. 동작·조건 대기 10초	P	클릭·이동·expect 설정 최대10초, viewportReadiness의 폰트·유한 애니메이션·기하 안정화 한 poll, 수동 도착/완료 lazyConditionWait의 첫 await부터10초와 timer 취소를 확인했다. 지연 응답 route.fetch도10초이며 공유 beforeAll의 별도 예산과 CASE 개별 준비를 구분한다. 소스1 소스2
13. CASE 전체 재시도 0	P	config retries0이며 CASE/file override로전체CASE재시도를켜지않는다. reporter는result.retry!==0을거절한다.같은조건의한정poll/제품의사용자재조회는자동CASE재시도가아니다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정본 viewport22/117checkpoint/22control이 누락 없이 선택되고 각 required reporter와 통합 e2e-evidence 단계가 local-1788983964771-26036에서 pass했다. 이 CASE의 실제 retry0·빈 skip/fixme annotations·expectedStatus passed를 대조했고 재시도/예상실패/누락을 거절하는 집행 회귀도 확인했다. 이는 승인된 browser+viewport 부분 실행의 실제 필수 gate 증거이며 full CI·hosted 승격 완료로 확대 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	정확히1개 진단 attachment의 CASE title/정확SHA/run/attempt/project/locale/timezone/start/end를 해당 결과와 대조했다. 실제 CDP document/loader 세대, request/protocol ID·method/path/status/terminal, control 정상·주입·negative·복원 시각과 문서 연결, close 이후 listener 정리 기록을 확인했다. 보류 요청은 같은 실제 request/document와 phase로 연결됐다. 이 정상 실행의 firstFailure/cleanupFailure는 null이며 이를 실패 경로 증명으로 쓰지 않는다. 현재 SHA에서 실제 viewport reload/hold/first-failure, teardown 중단의 조기 진단 보존, 민감값 제거 회귀를 별도 연결했다. 소스1 소스2

</details>

<a id="case-64"></a> <details><summary>V7 wide-touch 984x1092 — V7 wide-touch 984x1092 (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	실제 입력·행동·단언으로 목적을 확정했다: V7의 명시된 viewport·DPR·touch 조건에서 home/calendar/volume/feed/profile 5개 화면의 가로 넘침, 컬럼 폭, 호스트 배경을 검사한다. 검증 계층: 실제 로그인 앱의 DOM rect·scrollWidth·computedStyle. 픽셀 완전일치나 기기 네이티브 렌더링 전체를 주장하지 않는다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	시작 입력의 소스 근거: 공유 준비에서 일회용 계정과 완료 운동 4건·통계 fixture를 만든다. 각 CASE는 새로운 context에서 지정 viewport/DPR/touch를 쓰며, 업무 날짜와 locale/timezone은 명시한다. 날짜는 명시된 geometry/feature fixture 입력이며 난수UUID는 계정·mutation 격리용이다. 실제 새 실행 환경 일치 증거는 별도 runtime 항목으로 남긴다. 소스1 소스2
3. 독립 실행	P	전용 일회용 계정과 CASE별 새 context/page를 사용한다. workers1에서만 이 공유 fixture를 실행하며 다른 CASE 결과를 입력으로 쓰지 않는다. DB cron scope는 명시 격리 sandbox를 확인하고 teardown에서 복원한다. 실제 성공/실패 정리 완료는 기준10에서 별도 U다. 소스1 소스2
4. 상태·사건에 따른 순서	P	상태·사건으로 순서 제어: 지정 context에서 실제 탭의 visible view와 레이아웃 안정 상태를 확인한 뒤 측정한다. 필요한 response/visible/배치정착을 기다리며 고정 sleep·networkidle만으로 준비를 판정하지 않는다. 단일 조건 대기는 lazyConditionWait와 viewportReadiness의 10초 경계로 제어한다. 개별 통계 준비는 해당 owner의 실제 세대를 읽어 단일10초 deadline으로 완료시키는 경로로 연결됐다. 응답 주입 CASE는 실제 현재 문서의 요청 ID와 주입 구간을 별도 기록한다. 소스1 소스2
5. 독립적인 정답	P	독립 기대값의 실제 근거: 독립 기기 표의 기대 폭 600px, document/screen 가로 넘침 0, 비투명 배경을 사용한다. 앱의 폭 계산 함수를 다시 호출하지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	984×1092 wide-touch 실제 context에서 5개 탭과 고정 600px 컬럼을 측정했다. local-1788983964771-26036의 해당 CASE checkpoint 5개와 실제 단언 위치/종료를 원래 소스 조건에 대조했다. 실제 context/document와 정상 reader 값도 함께 확인했다. 소스1 소스2
7. 경계와 금지된 부작용	P	해당 목적의 경계·금지결과: 같은 viewport에서 5개 탭을 모두 열며 문서와 내부 screen 양쪽 넘침을 확인한다. 넓은 touch·가로 화면·pointer·desktop은 별도 정확한 title CASE들로 필수 목록에 연결된다. DB 저장·권한 부작용은 이 기하 CASE의 검증 범위가 아니다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	정본의 5개 필수 checkpoint가 정확히 한 번씩 완료됐고 그 안의 실제 단언 30개가 끝났다. 해당 CASE는 firstAttempt=true이며 missing/duplicate/swallowed/unfinished 오류가 없다. 실제 Playwright 우회·미완료 거절 및 성공 poll 내부 샘플 구분 회귀를 별도 연결했다. 단언 개수만으로 목적을 승인하지 않고 기준6의 실제 상황과 원래 단언 소스에 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	viewport-v7-column-width가 'V7 home'에서 실제 변경1회를 기록했다. 동일 reader/comparator의 정상 600 → 결함 632(불일치) → 복원 600(정상 재일치)를 확인했다. home의 실제 device width를 기대 폭+32px로 변경하고 동일 readViewportMetrics().column과 고정 표 기대값으로 불일치를 판정한다. home 폭 결함의 대표 증거이며 다른 4개 탭의 모든 CSS 결함에 대한 mutation 증거는 아니다. home 컬럼 폭의 DOM/CSS 경계 대표 결함만 대조한다. 현재 SHA의 실제 DOM/CSS mutation·복원 회귀와 무변경/예외/timeout 오인 거절 엔진 회귀를 연결했다. 이 판정은 해당 UI 경계 대표 결함이며 모든 단언 또는 제품 DB/권한/원자성 source mutant 탐지 범위를 주장하지 않는다. 소스1 소스2
10. 성공·실패의 자원 정리	P	이 CASE의 owned-cleanup이 completed=true이고 모든 context/control/route 자원이 settled/pass다. 실제 page close와 그 뒤 observer disposal/남은 owned listener0을 확인했다. 같은 CASE afterEach 또는 같은 spec의 공유 afterAll이 완료돼 계정·cron 정리 경로도 끝났다. 공유 afterAll은 마지막 CASE stream에 기록된 동일 공유fixture hook을 인용하며 다른 CASE의 본문을 근거로 쓰지 않았다. 실제 기본/수동 context의 본문 실패 경로 및 close/acquire 실패 보존 회귀도 연결했다. 종료 시 역사적 pending 요청은 pageClosed와 구별해 보존하며 정상 응답 완료로 바꾸지 않았다. 소스1 소스2
11. 준비+본문 60초	P	해당 native test의 effective timeout은60000ms이고 최초 시도 duration은4174ms로 개별 준비+본문 60초 한도 안에 끝났다. 공유 beforeAll과 teardown은 별도 hook 예산으로 구분했다. 동작별10초는 현재 소스 기준12 및 별도 bounded-wait 회귀로 확인하며 이 총시간만으로 대체하지 않는다. 소스1 소스2
12. 동작·조건 대기 10초	P	클릭·이동·expect 설정 최대10초, viewportReadiness의 폰트·유한 애니메이션·기하 안정화 한 poll, 수동 도착/완료 lazyConditionWait의 첫 await부터10초와 timer 취소를 확인했다. 지연 응답 route.fetch도10초이며 공유 beforeAll의 별도 예산과 CASE 개별 준비를 구분한다. 소스1 소스2
13. CASE 전체 재시도 0	P	config retries0이며 CASE/file override로전체CASE재시도를켜지않는다. reporter는result.retry!==0을거절한다.같은조건의한정poll/제품의사용자재조회는자동CASE재시도가아니다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정본 viewport22/117checkpoint/22control이 누락 없이 선택되고 각 required reporter와 통합 e2e-evidence 단계가 local-1788983964771-26036에서 pass했다. 이 CASE의 실제 retry0·빈 skip/fixme annotations·expectedStatus passed를 대조했고 재시도/예상실패/누락을 거절하는 집행 회귀도 확인했다. 이는 승인된 browser+viewport 부분 실행의 실제 필수 gate 증거이며 full CI·hosted 승격 완료로 확대 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	정확히1개 진단 attachment의 CASE title/정확SHA/run/attempt/project/locale/timezone/start/end를 해당 결과와 대조했다. 실제 CDP document/loader 세대, request/protocol ID·method/path/status/terminal, control 정상·주입·negative·복원 시각과 문서 연결, close 이후 listener 정리 기록을 확인했다. 보류 요청은 같은 실제 request/document와 phase로 연결됐다. 이 정상 실행의 firstFailure/cleanupFailure는 null이며 이를 실패 경로 증명으로 쓰지 않는다. 현재 SHA에서 실제 viewport reload/hold/first-failure, teardown 중단의 조기 진단 보존, 민감값 제거 회귀를 별도 연결했다. 소스1 소스2

</details>

<a id="case-65"></a> <details><summary>V8 wide-touch 932x440 — V8 wide-touch 932x440 (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	실제 입력·행동·단언으로 목적을 확정했다: V8의 명시된 viewport·DPR·touch 조건에서 home/calendar/volume/feed/profile 5개 화면의 가로 넘침, 컬럼 폭, 호스트 배경을 검사한다. 검증 계층: 실제 로그인 앱의 DOM rect·scrollWidth·computedStyle. 픽셀 완전일치나 기기 네이티브 렌더링 전체를 주장하지 않는다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	시작 입력의 소스 근거: 공유 준비에서 일회용 계정과 완료 운동 4건·통계 fixture를 만든다. 각 CASE는 새로운 context에서 지정 viewport/DPR/touch를 쓰며, 업무 날짜와 locale/timezone은 명시한다. 날짜는 명시된 geometry/feature fixture 입력이며 난수UUID는 계정·mutation 격리용이다. 실제 새 실행 환경 일치 증거는 별도 runtime 항목으로 남긴다. 소스1 소스2
3. 독립 실행	P	전용 일회용 계정과 CASE별 새 context/page를 사용한다. workers1에서만 이 공유 fixture를 실행하며 다른 CASE 결과를 입력으로 쓰지 않는다. DB cron scope는 명시 격리 sandbox를 확인하고 teardown에서 복원한다. 실제 성공/실패 정리 완료는 기준10에서 별도 U다. 소스1 소스2
4. 상태·사건에 따른 순서	P	상태·사건으로 순서 제어: 지정 context에서 실제 탭의 visible view와 레이아웃 안정 상태를 확인한 뒤 측정한다. 필요한 response/visible/배치정착을 기다리며 고정 sleep·networkidle만으로 준비를 판정하지 않는다. 단일 조건 대기는 lazyConditionWait와 viewportReadiness의 10초 경계로 제어한다. 개별 통계 준비는 해당 owner의 실제 세대를 읽어 단일10초 deadline으로 완료시키는 경로로 연결됐다. 응답 주입 CASE는 실제 현재 문서의 요청 ID와 주입 구간을 별도 기록한다. 소스1 소스2
5. 독립적인 정답	P	독립 기대값의 실제 근거: 독립 기기 표의 기대 폭 600px, document/screen 가로 넘침 0, 비투명 배경을 사용한다. 앱의 폭 계산 함수를 다시 호출하지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	932×440 landscape wide-touch 실제 context에서 5개 탭과 고정 600px 컬럼을 측정했다. local-1788983964771-26036의 해당 CASE checkpoint 5개와 실제 단언 위치/종료를 원래 소스 조건에 대조했다. 실제 context/document와 정상 reader 값도 함께 확인했다. 소스1 소스2
7. 경계와 금지된 부작용	P	해당 목적의 경계·금지결과: 같은 viewport에서 5개 탭을 모두 열며 문서와 내부 screen 양쪽 넘침을 확인한다. 넓은 touch·가로 화면·pointer·desktop은 별도 정확한 title CASE들로 필수 목록에 연결된다. DB 저장·권한 부작용은 이 기하 CASE의 검증 범위가 아니다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	정본의 5개 필수 checkpoint가 정확히 한 번씩 완료됐고 그 안의 실제 단언 30개가 끝났다. 해당 CASE는 firstAttempt=true이며 missing/duplicate/swallowed/unfinished 오류가 없다. 실제 Playwright 우회·미완료 거절 및 성공 poll 내부 샘플 구분 회귀를 별도 연결했다. 단언 개수만으로 목적을 승인하지 않고 기준6의 실제 상황과 원래 단언 소스에 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	viewport-v8-column-width가 'V8 home'에서 실제 변경1회를 기록했다. 동일 reader/comparator의 정상 600 → 결함 632(불일치) → 복원 600(정상 재일치)를 확인했다. home의 실제 device width를 기대 폭+32px로 변경하고 동일 readViewportMetrics().column과 고정 표 기대값으로 불일치를 판정한다. home 폭 결함의 대표 증거이며 다른 4개 탭의 모든 CSS 결함에 대한 mutation 증거는 아니다. home 컬럼 폭의 DOM/CSS 경계 대표 결함만 대조한다. 현재 SHA의 실제 DOM/CSS mutation·복원 회귀와 무변경/예외/timeout 오인 거절 엔진 회귀를 연결했다. 이 판정은 해당 UI 경계 대표 결함이며 모든 단언 또는 제품 DB/권한/원자성 source mutant 탐지 범위를 주장하지 않는다. 소스1 소스2
10. 성공·실패의 자원 정리	P	이 CASE의 owned-cleanup이 completed=true이고 모든 context/control/route 자원이 settled/pass다. 실제 page close와 그 뒤 observer disposal/남은 owned listener0을 확인했다. 같은 CASE afterEach 또는 같은 spec의 공유 afterAll이 완료돼 계정·cron 정리 경로도 끝났다. 공유 afterAll은 마지막 CASE stream에 기록된 동일 공유fixture hook을 인용하며 다른 CASE의 본문을 근거로 쓰지 않았다. 실제 기본/수동 context의 본문 실패 경로 및 close/acquire 실패 보존 회귀도 연결했다. 종료 시 역사적 pending 요청은 pageClosed와 구별해 보존하며 정상 응답 완료로 바꾸지 않았다. 소스1 소스2
11. 준비+본문 60초	P	해당 native test의 effective timeout은60000ms이고 최초 시도 duration은4148ms로 개별 준비+본문 60초 한도 안에 끝났다. 공유 beforeAll과 teardown은 별도 hook 예산으로 구분했다. 동작별10초는 현재 소스 기준12 및 별도 bounded-wait 회귀로 확인하며 이 총시간만으로 대체하지 않는다. 소스1 소스2
12. 동작·조건 대기 10초	P	클릭·이동·expect 설정 최대10초, viewportReadiness의 폰트·유한 애니메이션·기하 안정화 한 poll, 수동 도착/완료 lazyConditionWait의 첫 await부터10초와 timer 취소를 확인했다. 지연 응답 route.fetch도10초이며 공유 beforeAll의 별도 예산과 CASE 개별 준비를 구분한다. 소스1 소스2
13. CASE 전체 재시도 0	P	config retries0이며 CASE/file override로전체CASE재시도를켜지않는다. reporter는result.retry!==0을거절한다.같은조건의한정poll/제품의사용자재조회는자동CASE재시도가아니다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정본 viewport22/117checkpoint/22control이 누락 없이 선택되고 각 required reporter와 통합 e2e-evidence 단계가 local-1788983964771-26036에서 pass했다. 이 CASE의 실제 retry0·빈 skip/fixme annotations·expectedStatus passed를 대조했고 재시도/예상실패/누락을 거절하는 집행 회귀도 확인했다. 이는 승인된 browser+viewport 부분 실행의 실제 필수 gate 증거이며 full CI·hosted 승격 완료로 확대 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	정확히1개 진단 attachment의 CASE title/정확SHA/run/attempt/project/locale/timezone/start/end를 해당 결과와 대조했다. 실제 CDP document/loader 세대, request/protocol ID·method/path/status/terminal, control 정상·주입·negative·복원 시각과 문서 연결, close 이후 listener 정리 기록을 확인했다. 보류 요청은 같은 실제 request/document와 phase로 연결됐다. 이 정상 실행의 firstFailure/cleanupFailure는 null이며 이를 실패 경로 증명으로 쓰지 않는다. 현재 SHA에서 실제 viewport reload/hold/first-failure, teardown 중단의 조기 진단 보존, 민감값 제거 회귀를 별도 연결했다. 소스1 소스2

</details>

<a id="case-66"></a> <details><summary>P1 pointer-mockup 800x900 — P1 pointer-mockup 800x900 (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	실제 입력·행동·단언으로 목적을 확정했다: P1의 명시된 viewport·DPR·touch 조건에서 home/calendar/volume/feed/profile 5개 화면의 가로 넘침, 컬럼 폭, 호스트 배경을 검사한다. 검증 계층: 실제 로그인 앱의 DOM rect·scrollWidth·computedStyle. 픽셀 완전일치나 기기 네이티브 렌더링 전체를 주장하지 않는다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	시작 입력의 소스 근거: 공유 준비에서 일회용 계정과 완료 운동 4건·통계 fixture를 만든다. 각 CASE는 새로운 context에서 지정 viewport/DPR/touch를 쓰며, 업무 날짜와 locale/timezone은 명시한다. 날짜는 명시된 geometry/feature fixture 입력이며 난수UUID는 계정·mutation 격리용이다. 실제 새 실행 환경 일치 증거는 별도 runtime 항목으로 남긴다. 소스1 소스2
3. 독립 실행	P	전용 일회용 계정과 CASE별 새 context/page를 사용한다. workers1에서만 이 공유 fixture를 실행하며 다른 CASE 결과를 입력으로 쓰지 않는다. DB cron scope는 명시 격리 sandbox를 확인하고 teardown에서 복원한다. 실제 성공/실패 정리 완료는 기준10에서 별도 U다. 소스1 소스2
4. 상태·사건에 따른 순서	P	상태·사건으로 순서 제어: 지정 context에서 실제 탭의 visible view와 레이아웃 안정 상태를 확인한 뒤 측정한다. 필요한 response/visible/배치정착을 기다리며 고정 sleep·networkidle만으로 준비를 판정하지 않는다. 단일 조건 대기는 lazyConditionWait와 viewportReadiness의 10초 경계로 제어한다. 개별 통계 준비는 해당 owner의 실제 세대를 읽어 단일10초 deadline으로 완료시키는 경로로 연결됐다. 응답 주입 CASE는 실제 현재 문서의 요청 ID와 주입 구간을 별도 기록한다. 소스1 소스2
5. 독립적인 정답	P	독립 기대값의 실제 근거: 독립 기기 표의 기대 폭 390px, document/screen 가로 넘침 0, 비투명 배경을 사용한다. 앱의 폭 계산 함수를 다시 호출하지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	800×900 pointer mockup 실제 context에서 5개 탭과 고정 390px 컬럼을 측정했다. local-1788983964771-26036의 해당 CASE checkpoint 5개와 실제 단언 위치/종료를 원래 소스 조건에 대조했다. 실제 context/document와 정상 reader 값도 함께 확인했다. 소스1 소스2
7. 경계와 금지된 부작용	P	해당 목적의 경계·금지결과: 같은 viewport에서 5개 탭을 모두 열며 문서와 내부 screen 양쪽 넘침을 확인한다. 넓은 touch·가로 화면·pointer·desktop은 별도 정확한 title CASE들로 필수 목록에 연결된다. DB 저장·권한 부작용은 이 기하 CASE의 검증 범위가 아니다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	정본의 5개 필수 checkpoint가 정확히 한 번씩 완료됐고 그 안의 실제 단언 30개가 끝났다. 해당 CASE는 firstAttempt=true이며 missing/duplicate/swallowed/unfinished 오류가 없다. 실제 Playwright 우회·미완료 거절 및 성공 poll 내부 샘플 구분 회귀를 별도 연결했다. 단언 개수만으로 목적을 승인하지 않고 기준6의 실제 상황과 원래 단언 소스에 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	viewport-p1-column-width가 'P1 home'에서 실제 변경1회를 기록했다. 동일 reader/comparator의 정상 390 → 결함 422(불일치) → 복원 390(정상 재일치)를 확인했다. home의 실제 device width를 기대 폭+32px로 변경하고 동일 readViewportMetrics().column과 고정 표 기대값으로 불일치를 판정한다. home 폭 결함의 대표 증거이며 다른 4개 탭의 모든 CSS 결함에 대한 mutation 증거는 아니다. home 컬럼 폭의 DOM/CSS 경계 대표 결함만 대조한다. 현재 SHA의 실제 DOM/CSS mutation·복원 회귀와 무변경/예외/timeout 오인 거절 엔진 회귀를 연결했다. 이 판정은 해당 UI 경계 대표 결함이며 모든 단언 또는 제품 DB/권한/원자성 source mutant 탐지 범위를 주장하지 않는다. 소스1 소스2
10. 성공·실패의 자원 정리	P	이 CASE의 owned-cleanup이 completed=true이고 모든 context/control/route 자원이 settled/pass다. 실제 page close와 그 뒤 observer disposal/남은 owned listener0을 확인했다. 같은 CASE afterEach 또는 같은 spec의 공유 afterAll이 완료돼 계정·cron 정리 경로도 끝났다. 공유 afterAll은 마지막 CASE stream에 기록된 동일 공유fixture hook을 인용하며 다른 CASE의 본문을 근거로 쓰지 않았다. 실제 기본/수동 context의 본문 실패 경로 및 close/acquire 실패 보존 회귀도 연결했다. 종료 시 역사적 pending 요청은 pageClosed와 구별해 보존하며 정상 응답 완료로 바꾸지 않았다. 소스1 소스2
11. 준비+본문 60초	P	해당 native test의 effective timeout은60000ms이고 최초 시도 duration은4094ms로 개별 준비+본문 60초 한도 안에 끝났다. 공유 beforeAll과 teardown은 별도 hook 예산으로 구분했다. 동작별10초는 현재 소스 기준12 및 별도 bounded-wait 회귀로 확인하며 이 총시간만으로 대체하지 않는다. 소스1 소스2
12. 동작·조건 대기 10초	P	클릭·이동·expect 설정 최대10초, viewportReadiness의 폰트·유한 애니메이션·기하 안정화 한 poll, 수동 도착/완료 lazyConditionWait의 첫 await부터10초와 timer 취소를 확인했다. 지연 응답 route.fetch도10초이며 공유 beforeAll의 별도 예산과 CASE 개별 준비를 구분한다. 소스1 소스2
13. CASE 전체 재시도 0	P	config retries0이며 CASE/file override로전체CASE재시도를켜지않는다. reporter는result.retry!==0을거절한다.같은조건의한정poll/제품의사용자재조회는자동CASE재시도가아니다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정본 viewport22/117checkpoint/22control이 누락 없이 선택되고 각 required reporter와 통합 e2e-evidence 단계가 local-1788983964771-26036에서 pass했다. 이 CASE의 실제 retry0·빈 skip/fixme annotations·expectedStatus passed를 대조했고 재시도/예상실패/누락을 거절하는 집행 회귀도 확인했다. 이는 승인된 browser+viewport 부분 실행의 실제 필수 gate 증거이며 full CI·hosted 승격 완료로 확대 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	정확히1개 진단 attachment의 CASE title/정확SHA/run/attempt/project/locale/timezone/start/end를 해당 결과와 대조했다. 실제 CDP document/loader 세대, request/protocol ID·method/path/status/terminal, control 정상·주입·negative·복원 시각과 문서 연결, close 이후 listener 정리 기록을 확인했다. 보류 요청은 같은 실제 request/document와 phase로 연결됐다. 이 정상 실행의 firstFailure/cleanupFailure는 null이며 이를 실패 경로 증명으로 쓰지 않는다. 현재 SHA에서 실제 viewport reload/hold/first-failure, teardown 중단의 조기 진단 보존, 민감값 제거 회귀를 별도 연결했다. 소스1 소스2

</details>

<a id="case-67"></a> <details><summary>D1 desktop 1440x900 — D1 desktop 1440x900 (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	실제 입력·행동·단언으로 목적을 확정했다: D1 desktop의 zoom 계약값·하한에 따른 overflow·비투명 배경을 확인한다. 검증 계층: 실제 desktop host의 CSS custom property/computed overflow/background. 실제 확대 비율의 모든 자식 rect·시각 픽셀까지 검사하는 CASE는 아니다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	시작 입력의 소스 근거: 일회용 계정·완료 세션·통계 fixture를 공유 준비하고 CASE별 새 pointer context에서 명시 viewport를 사용한다. 날짜는 명시된 geometry/feature fixture 입력이며 난수UUID는 계정·mutation 격리용이다. 실제 새 실행 환경 일치 증거는 별도 runtime 항목으로 남긴다. 소스1 소스2
3. 독립 실행	P	전용 일회용 계정과 CASE별 새 context/page를 사용한다. workers1에서만 이 공유 fixture를 실행하며 다른 CASE 결과를 입력으로 쓰지 않는다. DB cron scope는 명시 격리 sandbox를 확인하고 teardown에서 복원한다. 실제 성공/실패 정리 완료는 기준10에서 별도 U다. 소스1 소스2
4. 상태·사건에 따른 순서	P	상태·사건으로 순서 제어: 실제 desktop host가 보이고 기하가 안정된 뒤 CSS 계약값을 읽는다. 필요한 response/visible/배치정착을 기다리며 고정 sleep·networkidle만으로 준비를 판정하지 않는다. 단일 조건 대기는 lazyConditionWait와 viewportReadiness의 10초 경계로 제어한다. 개별 통계 준비는 해당 owner의 실제 세대를 읽어 단일10초 deadline으로 완료시키는 경로로 연결됐다. 응답 주입 CASE는 실제 현재 문서의 요청 ID와 주입 구간을 별도 기록한다. 소스1 소스2
5. 독립적인 정답	P	독립 기대값의 실제 근거: 기대 zoom 1440/1913와 clamp 여부를 독립 표에서 정한다. 소수 3자리의 같은 closeTo 비교 규칙을 정상 단언과 control에 적용한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	1440×900 desktop에서 실제 zoom·가로 넘침·화면 상단 위치를 측정했다. local-1788983964771-26036의 해당 CASE checkpoint 1개와 실제 단언 위치/종료를 원래 소스 조건에 대조했다. 실제 context/document와 정상 reader 값도 함께 확인했다. 소스1 소스2
7. 경계와 금지된 부작용	P	해당 목적의 경계·금지결과: D1 비하한과 D3 하한을 별도 필수 CASE로 연결하고 overflow가 각각 hidden/auto인지 확인한다. 해당 CSS 계약에 unrelated DB mutation이나 다른 계정 부작용을 요구하지 않는다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	정본의 1개 필수 checkpoint가 정확히 한 번씩 완료됐고 그 안의 실제 단언 3개가 끝났다. 해당 CASE는 firstAttempt=true이며 missing/duplicate/swallowed/unfinished 오류가 없다. 실제 Playwright 우회·미완료 거절 및 성공 poll 내부 샘플 구분 회귀를 별도 연결했다. 단언 개수만으로 목적을 승인하지 않고 기준6의 실제 상황과 원래 단언 소스에 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	viewport-d1-desktop-zoom가 'desktop geometry'에서 실제 변경1회를 기록했다. 동일 reader/comparator의 정상 0.7527443805541035 → 결함 0.8777443805541035(불일치) → 복원 0.7527443805541035(정상 재일치)를 확인했다. 동일 desktop metrics reader의 zoom 값에 대해 실제 --lg-desktop-root-zoom을 기대값+0.125로 바꾸고 같은 closeTo(3) 판정이 불일치하는지 확인한다. CSS zoom 값 계약의 검증이며 제품 zoom 계산 함수를 제거한 mutant나 전체 자식 배율의 검증은 아니다. 현재 SHA의 실제 DOM/CSS mutation·복원 회귀와 무변경/예외/timeout 오인 거절 엔진 회귀를 연결했다. 이 판정은 해당 UI 경계 대표 결함이며 모든 단언 또는 제품 DB/권한/원자성 source mutant 탐지 범위를 주장하지 않는다. 소스1 소스2
10. 성공·실패의 자원 정리	P	이 CASE의 owned-cleanup이 completed=true이고 모든 context/control/route 자원이 settled/pass다. 실제 page close와 그 뒤 observer disposal/남은 owned listener0을 확인했다. 같은 CASE afterEach 또는 같은 spec의 공유 afterAll이 완료돼 계정·cron 정리 경로도 끝났다. 공유 afterAll은 마지막 CASE stream에 기록된 동일 공유fixture hook을 인용하며 다른 CASE의 본문을 근거로 쓰지 않았다. 실제 기본/수동 context의 본문 실패 경로 및 close/acquire 실패 보존 회귀도 연결했다. 종료 시 역사적 pending 요청은 pageClosed와 구별해 보존하며 정상 응답 완료로 바꾸지 않았다. 소스1 소스2
11. 준비+본문 60초	P	해당 native test의 effective timeout은60000ms이고 최초 시도 duration은749ms로 개별 준비+본문 60초 한도 안에 끝났다. 공유 beforeAll과 teardown은 별도 hook 예산으로 구분했다. 동작별10초는 현재 소스 기준12 및 별도 bounded-wait 회귀로 확인하며 이 총시간만으로 대체하지 않는다. 소스1 소스2
12. 동작·조건 대기 10초	P	클릭·이동·expect 설정 최대10초, viewportReadiness의 폰트·유한 애니메이션·기하 안정화 한 poll, 수동 도착/완료 lazyConditionWait의 첫 await부터10초와 timer 취소를 확인했다. 지연 응답 route.fetch도10초이며 공유 beforeAll의 별도 예산과 CASE 개별 준비를 구분한다. 소스1 소스2
13. CASE 전체 재시도 0	P	config retries0이며 CASE/file override로전체CASE재시도를켜지않는다. reporter는result.retry!==0을거절한다.같은조건의한정poll/제품의사용자재조회는자동CASE재시도가아니다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정본 viewport22/117checkpoint/22control이 누락 없이 선택되고 각 required reporter와 통합 e2e-evidence 단계가 local-1788983964771-26036에서 pass했다. 이 CASE의 실제 retry0·빈 skip/fixme annotations·expectedStatus passed를 대조했고 재시도/예상실패/누락을 거절하는 집행 회귀도 확인했다. 이는 승인된 browser+viewport 부분 실행의 실제 필수 gate 증거이며 full CI·hosted 승격 완료로 확대 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	정확히1개 진단 attachment의 CASE title/정확SHA/run/attempt/project/locale/timezone/start/end를 해당 결과와 대조했다. 실제 CDP document/loader 세대, request/protocol ID·method/path/status/terminal, control 정상·주입·negative·복원 시각과 문서 연결, close 이후 listener 정리 기록을 확인했다. 보류 요청은 같은 실제 request/document와 phase로 연결됐다. 이 정상 실행의 firstFailure/cleanupFailure는 null이며 이를 실패 경로 증명으로 쓰지 않는다. 현재 SHA에서 실제 viewport reload/hold/first-failure, teardown 중단의 조기 진단 보존, 민감값 제거 회귀를 별도 연결했다. 소스1 소스2

</details>

<a id="case-68"></a> <details><summary>D3 desktop 1280x720 — D3 desktop 1280x720 (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	실제 입력·행동·단언으로 목적을 확정했다: D3 desktop의 zoom 계약값·하한에 따른 overflow·비투명 배경을 확인한다. 검증 계층: 실제 desktop host의 CSS custom property/computed overflow/background. 실제 확대 비율의 모든 자식 rect·시각 픽셀까지 검사하는 CASE는 아니다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	시작 입력의 소스 근거: 일회용 계정·완료 세션·통계 fixture를 공유 준비하고 CASE별 새 pointer context에서 명시 viewport를 사용한다. 날짜는 명시된 geometry/feature fixture 입력이며 난수UUID는 계정·mutation 격리용이다. 실제 새 실행 환경 일치 증거는 별도 runtime 항목으로 남긴다. 소스1 소스2
3. 독립 실행	P	전용 일회용 계정과 CASE별 새 context/page를 사용한다. workers1에서만 이 공유 fixture를 실행하며 다른 CASE 결과를 입력으로 쓰지 않는다. DB cron scope는 명시 격리 sandbox를 확인하고 teardown에서 복원한다. 실제 성공/실패 정리 완료는 기준10에서 별도 U다. 소스1 소스2
4. 상태·사건에 따른 순서	P	상태·사건으로 순서 제어: 실제 desktop host가 보이고 기하가 안정된 뒤 CSS 계약값을 읽는다. 필요한 response/visible/배치정착을 기다리며 고정 sleep·networkidle만으로 준비를 판정하지 않는다. 단일 조건 대기는 lazyConditionWait와 viewportReadiness의 10초 경계로 제어한다. 개별 통계 준비는 해당 owner의 실제 세대를 읽어 단일10초 deadline으로 완료시키는 경로로 연결됐다. 응답 주입 CASE는 실제 현재 문서의 요청 ID와 주입 구간을 별도 기록한다. 소스1 소스2
5. 독립적인 정답	P	독립 기대값의 실제 근거: 기대 zoom 0.7와 clamp 여부를 독립 표에서 정한다. 소수 3자리의 같은 closeTo 비교 규칙을 정상 단언과 control에 적용한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	1280×720 desktop에서 실제 zoom·가로 넘침·화면 상단 위치를 측정했다. local-1788983964771-26036의 해당 CASE checkpoint 1개와 실제 단언 위치/종료를 원래 소스 조건에 대조했다. 실제 context/document와 정상 reader 값도 함께 확인했다. 소스1 소스2
7. 경계와 금지된 부작용	P	해당 목적의 경계·금지결과: D1 비하한과 D3 하한을 별도 필수 CASE로 연결하고 overflow가 각각 hidden/auto인지 확인한다. 해당 CSS 계약에 unrelated DB mutation이나 다른 계정 부작용을 요구하지 않는다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	정본의 1개 필수 checkpoint가 정확히 한 번씩 완료됐고 그 안의 실제 단언 3개가 끝났다. 해당 CASE는 firstAttempt=true이며 missing/duplicate/swallowed/unfinished 오류가 없다. 실제 Playwright 우회·미완료 거절 및 성공 poll 내부 샘플 구분 회귀를 별도 연결했다. 단언 개수만으로 목적을 승인하지 않고 기준6의 실제 상황과 원래 단언 소스에 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	viewport-d3-desktop-zoom가 'desktop geometry'에서 실제 변경1회를 기록했다. 동일 reader/comparator의 정상 0.7 → 결함 0.825(불일치) → 복원 0.7(정상 재일치)를 확인했다. 동일 desktop metrics reader의 zoom 값에 대해 실제 --lg-desktop-root-zoom을 기대값+0.125로 바꾸고 같은 closeTo(3) 판정이 불일치하는지 확인한다. CSS zoom 값 계약의 검증이며 제품 zoom 계산 함수를 제거한 mutant나 전체 자식 배율의 검증은 아니다. 현재 SHA의 실제 DOM/CSS mutation·복원 회귀와 무변경/예외/timeout 오인 거절 엔진 회귀를 연결했다. 이 판정은 해당 UI 경계 대표 결함이며 모든 단언 또는 제품 DB/권한/원자성 source mutant 탐지 범위를 주장하지 않는다. 소스1 소스2
10. 성공·실패의 자원 정리	P	이 CASE의 owned-cleanup이 completed=true이고 모든 context/control/route 자원이 settled/pass다. 실제 page close와 그 뒤 observer disposal/남은 owned listener0을 확인했다. 같은 CASE afterEach 또는 같은 spec의 공유 afterAll이 완료돼 계정·cron 정리 경로도 끝났다. 공유 afterAll은 마지막 CASE stream에 기록된 동일 공유fixture hook을 인용하며 다른 CASE의 본문을 근거로 쓰지 않았다. 실제 기본/수동 context의 본문 실패 경로 및 close/acquire 실패 보존 회귀도 연결했다. 종료 시 역사적 pending 요청은 pageClosed와 구별해 보존하며 정상 응답 완료로 바꾸지 않았다. 소스1 소스2
11. 준비+본문 60초	P	해당 native test의 effective timeout은60000ms이고 최초 시도 duration은734ms로 개별 준비+본문 60초 한도 안에 끝났다. 공유 beforeAll과 teardown은 별도 hook 예산으로 구분했다. 동작별10초는 현재 소스 기준12 및 별도 bounded-wait 회귀로 확인하며 이 총시간만으로 대체하지 않는다. 소스1 소스2
12. 동작·조건 대기 10초	P	클릭·이동·expect 설정 최대10초, viewportReadiness의 폰트·유한 애니메이션·기하 안정화 한 poll, 수동 도착/완료 lazyConditionWait의 첫 await부터10초와 timer 취소를 확인했다. 지연 응답 route.fetch도10초이며 공유 beforeAll의 별도 예산과 CASE 개별 준비를 구분한다. 소스1 소스2
13. CASE 전체 재시도 0	P	config retries0이며 CASE/file override로전체CASE재시도를켜지않는다. reporter는result.retry!==0을거절한다.같은조건의한정poll/제품의사용자재조회는자동CASE재시도가아니다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정본 viewport22/117checkpoint/22control이 누락 없이 선택되고 각 required reporter와 통합 e2e-evidence 단계가 local-1788983964771-26036에서 pass했다. 이 CASE의 실제 retry0·빈 skip/fixme annotations·expectedStatus passed를 대조했고 재시도/예상실패/누락을 거절하는 집행 회귀도 확인했다. 이는 승인된 browser+viewport 부분 실행의 실제 필수 gate 증거이며 full CI·hosted 승격 완료로 확대 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	정확히1개 진단 attachment의 CASE title/정확SHA/run/attempt/project/locale/timezone/start/end를 해당 결과와 대조했다. 실제 CDP document/loader 세대, request/protocol ID·method/path/status/terminal, control 정상·주입·negative·복원 시각과 문서 연결, close 이후 listener 정리 기록을 확인했다. 보류 요청은 같은 실제 request/document와 phase로 연결됐다. 이 정상 실행의 firstFailure/cleanupFailure는 null이며 이를 실패 경로 증명으로 쓰지 않는다. 현재 SHA에서 실제 viewport reload/hold/first-failure, teardown 중단의 조기 진단 보존, 민감값 제거 회귀를 별도 연결했다. 소스1 소스2

</details>

<a id="case-69"></a> <details><summary>comment sheet: input row never overlaps the tabbar band — comment sheet: input row never overlaps the tabbar band (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	실제 입력·행동·단언으로 목적을 확정했다: 390x844 touch 화면에서 댓글 입력 행의 탭바 비중첩·화면 내 위치·hit test와 시트 닫힘 뒤 탭바 복원을 확인한다. 검증 계층: 실제 댓글 시트 DOM geometry와 elementFromPoint. 댓글 저장 API/DB는 범위 밖이다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	시작 입력의 소스 근거: 전용 계정의 실제 완료 세션으로 피드 댓글 시트를 열며 V3 context와 업무 날짜를 지정한다. 날짜는 명시된 geometry/feature fixture 입력이며 난수UUID는 계정·mutation 격리용이다. 실제 새 실행 환경 일치 증거는 별도 runtime 항목으로 남긴다. 소스1 소스2
3. 독립 실행	P	전용 일회용 계정과 CASE별 새 context/page를 사용한다. workers1에서만 이 공유 fixture를 실행하며 다른 CASE 결과를 입력으로 쓰지 않는다. DB cron scope는 명시 격리 sandbox를 확인하고 teardown에서 복원한다. 실제 성공/실패 정리 완료는 기준10에서 별도 U다. 소스1 소스2
4. 상태·사건에 따른 순서	P	상태·사건으로 순서 제어: 실제 피드 세션의 댓글 시트를 연 뒤 유한 애니메이션과 배치가 안정된 상태를 읽는다. 필요한 response/visible/배치정착을 기다리며 고정 sleep·networkidle만으로 준비를 판정하지 않는다. 단일 조건 대기는 lazyConditionWait와 viewportReadiness의 10초 경계로 제어한다. 개별 통계 준비는 해당 owner의 실제 세대를 읽어 단일10초 deadline으로 완료시키는 경로로 연결됐다. 응답 주입 CASE는 실제 현재 문서의 요청 ID와 주입 구간을 별도 기록한다. 소스1 소스2
5. 독립적인 정답	P	독립 기대값의 실제 근거: 탭바 display none, 교집합 면적 0, 입력 행의 화면 내 위치와 hit-test true라는 독립 구조 조건을 적용한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	실제 댓글 sheet를 열어 입력 행의 viewport 내 위치를 측정하고 sheet 종료와 tabbar 복귀를 확인했다. local-1788983964771-26036의 해당 CASE checkpoint 2개와 실제 단언 위치/종료를 원래 소스 조건에 대조했다. 실제 context/document와 정상 reader 값도 함께 확인했다. 소스1 소스2
7. 경계와 금지된 부작용	P	해당 목적의 경계·금지결과: 시트 열림 때 겹침·입력 접근성을 확인하고 닫힘 때 시트 제거와 탭바 복원을 확인한다. 390x844 이외 전 기기 댓글 시트 검증으로 보고하지 않는다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	정본의 2개 필수 checkpoint가 정확히 한 번씩 완료됐고 그 안의 실제 단언 7개가 끝났다. 해당 CASE는 firstAttempt=true이며 missing/duplicate/swallowed/unfinished 오류가 없다. 실제 Playwright 우회·미완료 거절 및 성공 poll 내부 샘플 구분 회귀를 별도 연결했다. 단언 개수만으로 목적을 승인하지 않고 기준6의 실제 상황과 원래 단언 소스에 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	viewport-comment-input-outside가 'comment input geometry'에서 실제 변경1회를 기록했다. 동일 reader/comparator의 정상 true → 결함 false(불일치) → 복원 true(정상 재일치)를 확인했다. 실제 댓글 입력 form을 화면 높이 두 배 아래로 옮겨 동일 readCommentGeometry().formInViewport가 true에서 false로 바뀌는지 검사한다. 입력 행의 화면 밖 이탈을 대표한다. 탭바 display 자체를 되돌리는 별도 중첩 mutant는 아니다. 현재 SHA의 실제 DOM/CSS mutation·복원 회귀와 무변경/예외/timeout 오인 거절 엔진 회귀를 연결했다. 이 판정은 해당 UI 경계 대표 결함이며 모든 단언 또는 제품 DB/권한/원자성 source mutant 탐지 범위를 주장하지 않는다. 소스1 소스2
10. 성공·실패의 자원 정리	P	이 CASE의 owned-cleanup이 completed=true이고 모든 context/control/route 자원이 settled/pass다. 실제 page close와 그 뒤 observer disposal/남은 owned listener0을 확인했다. 같은 CASE afterEach 또는 같은 spec의 공유 afterAll이 완료돼 계정·cron 정리 경로도 끝났다. 공유 afterAll은 마지막 CASE stream에 기록된 동일 공유fixture hook을 인용하며 다른 CASE의 본문을 근거로 쓰지 않았다. 실제 기본/수동 context의 본문 실패 경로 및 close/acquire 실패 보존 회귀도 연결했다. 종료 시 역사적 pending 요청은 pageClosed와 구별해 보존하며 정상 응답 완료로 바꾸지 않았다. 소스1 소스2
11. 준비+본문 60초	P	해당 native test의 effective timeout은60000ms이고 최초 시도 duration은1811ms로 개별 준비+본문 60초 한도 안에 끝났다. 공유 beforeAll과 teardown은 별도 hook 예산으로 구분했다. 동작별10초는 현재 소스 기준12 및 별도 bounded-wait 회귀로 확인하며 이 총시간만으로 대체하지 않는다. 소스1 소스2
12. 동작·조건 대기 10초	P	클릭·이동·expect 설정 최대10초, viewportReadiness의 폰트·유한 애니메이션·기하 안정화 한 poll, 수동 도착/완료 lazyConditionWait의 첫 await부터10초와 timer 취소를 확인했다. 지연 응답 route.fetch도10초이며 공유 beforeAll의 별도 예산과 CASE 개별 준비를 구분한다. 소스1 소스2
13. CASE 전체 재시도 0	P	config retries0이며 CASE/file override로전체CASE재시도를켜지않는다. reporter는result.retry!==0을거절한다.같은조건의한정poll/제품의사용자재조회는자동CASE재시도가아니다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정본 viewport22/117checkpoint/22control이 누락 없이 선택되고 각 required reporter와 통합 e2e-evidence 단계가 local-1788983964771-26036에서 pass했다. 이 CASE의 실제 retry0·빈 skip/fixme annotations·expectedStatus passed를 대조했고 재시도/예상실패/누락을 거절하는 집행 회귀도 확인했다. 이는 승인된 browser+viewport 부분 실행의 실제 필수 gate 증거이며 full CI·hosted 승격 완료로 확대 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	정확히1개 진단 attachment의 CASE title/정확SHA/run/attempt/project/locale/timezone/start/end를 해당 결과와 대조했다. 실제 CDP document/loader 세대, request/protocol ID·method/path/status/terminal, control 정상·주입·negative·복원 시각과 문서 연결, close 이후 listener 정리 기록을 확인했다. 보류 요청은 같은 실제 request/document와 phase로 연결됐다. 이 정상 실행의 firstFailure/cleanupFailure는 null이며 이를 실패 경로 증명으로 쓰지 않는다. 현재 SHA에서 실제 viewport reload/hold/first-failure, teardown 중단의 조기 진단 보존, 민감값 제거 회귀를 별도 연결했다. 소스1 소스2

</details>

<a id="case-70"></a> <details><summary>workout dock states + tabbar + brand row geometry — workout dock states + tabbar + brand row geometry (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	실제 입력·행동·단언으로 목적을 확정했다: 운동 도크 5상태의 바닥 밀착·높이 항등, safe-bottom 0/34 및 safe-top 0/47 추종, 탭바·브랜드 행·기록 도구 스택의 geometry 계약을 확인한다. 검증 계층: 실제 앱 운동 상태 전이와 DOM/CSS 기하. 운동 저장 완료나 실제 iOS safe-area 전체는 검증하지 않는다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	시작 입력의 소스 근거: 전용 계정과 통계 fixture를 공유 준비하고, 390x844 touch context에서 2세트의 실제 운동 상태 전이를 만든다. 날짜는 명시된 geometry/feature fixture 입력이며 난수UUID는 계정·mutation 격리용이다. 실제 새 실행 환경 일치 증거는 별도 runtime 항목으로 남긴다. 소스1 소스2
3. 독립 실행	P	전용 일회용 계정과 CASE별 새 context/page를 사용한다. workers1에서만 이 공유 fixture를 실행하며 다른 CASE 결과를 입력으로 쓰지 않는다. DB cron scope는 명시 격리 sandbox를 확인하고 teardown에서 복원한다. 실제 성공/실패 정리 완료는 기준10에서 별도 U다. 소스1 소스2
4. 상태·사건에 따른 순서	P	상태·사건으로 순서 제어: 실제 운동 시작·세트 완료·휴식·종목 완료를 클릭하며 각 상태 selector의 실제 마운트를 확인한다. 필요한 response/visible/배치정착을 기다리며 고정 sleep·networkidle만으로 준비를 판정하지 않는다. 단일 조건 대기는 lazyConditionWait와 viewportReadiness의 10초 경계로 제어한다. 개별 통계 준비는 해당 owner의 실제 세대를 읽어 단일10초 deadline으로 완료시키는 경로로 연결됐다. 응답 주입 CASE는 실제 현재 문서의 요청 ID와 주입 구간을 별도 기록한다. 소스1 소스2
5. 독립적인 정답	P	독립 기대값의 실제 근거: safe 주입량 34/47 자체가 독립 기대 delta다. 채널 높이 104/50, 화면 여백 118/50/64/50·기록 도구62를 고정 계약값으로 검사한다. CSS token과의 비교 및 상태간 높이 비교는 소유권/동일성 요구의 관계식이며 절대 총높이의 독립 정답이라고 보고하지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	실제 운동을 5개 dock 상태로 전환하고 탭별 safe inset/brand·records layer·높이 합계와 바닥 부착을 측정했다. local-1788983964771-26036의 해당 CASE checkpoint 4개와 실제 단언 위치/종료를 원래 소스 조건에 대조했다. 실제 context/document와 정상 reader 값도 함께 확인했다. 소스1 소스2
7. 경계와 금지된 부작용	P	해당 목적의 경계·금지결과: 5상태×safe0/34, 4탭 브랜드행 존재·safe-top1회 가산, 도크 중 탭바 숨김, 기록 도구 왕복 뒤 홈채널 복원을 확인한다. enforcement flag는 현재 모두 true다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	정본의 4개 필수 checkpoint가 정확히 한 번씩 완료됐고 그 안의 실제 단언 171개가 끝났다. 해당 CASE는 firstAttempt=true이며 missing/duplicate/swallowed/unfinished 오류가 없다. 실제 Playwright 우회·미완료 거절 및 성공 poll 내부 샘플 구분 회귀를 별도 연결했다. 단언 개수만으로 목적을 승인하지 않고 기준6의 실제 상황과 원래 단언 소스에 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	viewport-dock-bottom-gap가 'drive live workout to the 5 dock states'에서 실제 변경1회를 기록했다. 동일 reader/comparator의 정상 true → 결함 false(불일치) → 복원 true(정상 재일치)를 확인했다. 실제 review dock을 32px 위로 옮겨 기존 measureDock().bottomFlush와 true 비교가 불일치하는지 검사한다. review dock 바닥 간격의 대표 결함이다. 모든 safe 계산/브랜드 정렬 mutant를 넣은 것은 아니다. 현재 SHA의 실제 DOM/CSS mutation·복원 회귀와 무변경/예외/timeout 오인 거절 엔진 회귀를 연결했다. 이 판정은 해당 UI 경계 대표 결함이며 모든 단언 또는 제품 DB/권한/원자성 source mutant 탐지 범위를 주장하지 않는다. 소스1 소스2
10. 성공·실패의 자원 정리	P	이 CASE의 owned-cleanup이 completed=true이고 모든 context/control/route 자원이 settled/pass다. 실제 page close와 그 뒤 observer disposal/남은 owned listener0을 확인했다. 같은 CASE afterEach 또는 같은 spec의 공유 afterAll이 완료돼 계정·cron 정리 경로도 끝났다. 공유 afterAll은 마지막 CASE stream에 기록된 동일 공유fixture hook을 인용하며 다른 CASE의 본문을 근거로 쓰지 않았다. 실제 기본/수동 context의 본문 실패 경로 및 close/acquire 실패 보존 회귀도 연결했다. 종료 시 역사적 pending 요청은 pageClosed와 구별해 보존하며 정상 응답 완료로 바꾸지 않았다. 소스1 소스2
11. 준비+본문 60초	P	해당 native test의 effective timeout은60000ms이고 최초 시도 duration은12135ms로 개별 준비+본문 60초 한도 안에 끝났다. 공유 beforeAll과 teardown은 별도 hook 예산으로 구분했다. 동작별10초는 현재 소스 기준12 및 별도 bounded-wait 회귀로 확인하며 이 총시간만으로 대체하지 않는다. 소스1 소스2
12. 동작·조건 대기 10초	P	클릭·이동·expect 설정 최대10초, viewportReadiness의 폰트·유한 애니메이션·기하 안정화 한 poll, 수동 도착/완료 lazyConditionWait의 첫 await부터10초와 timer 취소를 확인했다. 지연 응답 route.fetch도10초이며 공유 beforeAll의 별도 예산과 CASE 개별 준비를 구분한다. 소스1 소스2
13. CASE 전체 재시도 0	P	config retries0이며 CASE/file override로전체CASE재시도를켜지않는다. reporter는result.retry!==0을거절한다.같은조건의한정poll/제품의사용자재조회는자동CASE재시도가아니다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정본 viewport22/117checkpoint/22control이 누락 없이 선택되고 각 required reporter와 통합 e2e-evidence 단계가 local-1788983964771-26036에서 pass했다. 이 CASE의 실제 retry0·빈 skip/fixme annotations·expectedStatus passed를 대조했고 재시도/예상실패/누락을 거절하는 집행 회귀도 확인했다. 이는 승인된 browser+viewport 부분 실행의 실제 필수 gate 증거이며 full CI·hosted 승격 완료로 확대 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	정확히1개 진단 attachment의 CASE title/정확SHA/run/attempt/project/locale/timezone/start/end를 해당 결과와 대조했다. 실제 CDP document/loader 세대, request/protocol ID·method/path/status/terminal, control 정상·주입·negative·복원 시각과 문서 연결, close 이후 listener 정리 기록을 확인했다. 보류 요청은 같은 실제 request/document와 phase로 연결됐다. 이 정상 실행의 firstFailure/cleanupFailure는 null이며 이를 실패 경로 증명으로 쓰지 않는다. 현재 SHA에서 실제 viewport reload/hold/first-failure, teardown 중단의 조기 진단 보존, 민감값 제거 회귀를 별도 연결했다. 소스1 소스2

</details>

<a id="case-71"></a> <details><summary>16 surfaces: content never ends under the bottom chrome (safe 0/34) — 16 surfaces: content never ends under the bottom chrome (safe 0/34) (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	실제 입력·행동·단언으로 목적을 확정했다: 필수16개 목적 화면과 기존 friend-scope 추가1개에서 safe-bottom0/34 각각 콘텐츠 하단 여백·스크롤 끝 접근성·크롬 표시채널을 검사한다. 검증 계층: 실제 화면 DOM geometry/hit test. 하단 콘텐츠 접근성 검사이며 각 화면의 모든 저장 비즈니스 기능을 보장하지 않는다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	시작 입력의 소스 근거: 일회용 본인/친구 계정, 넘침을 강제하는 하루3세션×4종목×3세트, 추가 세션·팔로우·그룹·통계 fixture를 만든다. 날짜는 명시된 geometry/feature fixture 입력이며 난수UUID는 계정·mutation 격리용이다. 실제 새 실행 환경 일치 증거는 별도 runtime 항목으로 남긴다. 소스1 소스2
3. 독립 실행	P	전용 일회용 계정과 CASE별 새 context/page를 사용한다. workers1에서만 이 공유 fixture를 실행하며 다른 CASE 결과를 입력으로 쓰지 않는다. DB cron scope는 명시 격리 sandbox를 확인하고 teardown에서 복원한다. 실제 성공/실패 정리 완료는 기준10에서 별도 U다. 소스1 소스2
4. 상태·사건에 따른 순서	P	상태·사건으로 순서 제어: 실제 17표면×2safe를 측정하고 journal-day 넘침·친구일지·PR 목록 진입을 필수로 확인한다. 필요한 response/visible/배치정착을 기다리며 고정 sleep·networkidle만으로 준비를 판정하지 않는다. 단일 조건 대기는 lazyConditionWait와 viewportReadiness의 10초 경계로 제어한다. 개별 통계 준비는 해당 owner의 실제 세대를 읽어 단일10초 deadline으로 완료시키는 경로로 연결됐다. 응답 주입 CASE는 실제 현재 문서의 요청 ID와 주입 구간을 별도 기록한다. 소스1 소스2
5. 독립적인 정답	P	독립 기대값의 실제 근거: 내용 하단≤실제 크롬 상단+0.5px, 스크롤 끝 최하단 대화요소가 크롬 위에 있고 hit-test true라는 독립 구조 요구다. 표현 코드의 padding 계산을 기대값으로 재호출하지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	필수16표면과 유지된 friend-scope까지 17표면×safe0/34를 실제 측정하고 마지막 정확한 ID/variant 집합 단언을 완료했다. local-1788983964771-26036의 해당 CASE checkpoint 35개와 실제 단언 위치/종료를 원래 소스 조건에 대조했다. 실제 context/document와 정상 reader 값도 함께 확인했다. 소스1 소스2
7. 경계와 금지된 부작용	P	해당 목적의 경계·금지결과: 정확한 required16 ID+friend-scope와 safe0/34를 계약에서 대조한다. journal-day는 실제 overflow>1 및 마지막 addPastRecordButton을 필수 단언한다. 넘침이 없는 표면의 reach 생략은 명시된 scope이며, friend-journal 진입은 이제 조건부가 아니다. 월 경계는 seed month로 이동한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	정본의 35개 필수 checkpoint가 정확히 한 번씩 완료됐고 그 안의 실제 단언 257개가 끝났다. 해당 CASE는 firstAttempt=true이며 missing/duplicate/swallowed/unfinished 오류가 없다. 실제 Playwright 우회·미완료 거절 및 성공 poll 내부 샘플 구분 회귀를 별도 연결했다. 단언 개수만으로 목적을 승인하지 않고 기준6의 실제 상황과 원래 단언 소스에 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	viewport-journal-day-clearance가 'surface: journal-day safe 0'에서 실제 변경1회를 기록했다. 동일 reader/comparator의 정상 true → 결함 false(불일치) → 복원 true(정상 재일치)를 확인했다. journal-day safe0에서 실제 padding-bottom을0으로 바꾸고 동일 measure reader의 contentBottom≤chromeTop+0.5 판정이 깨지는지 확인한다. #1250 journal-day 여백 결함을 대표한다. 다른16표면의 개별 제품 mutant까지 실행했다고 주장하지 않는다. 현재 SHA의 실제 DOM/CSS mutation·복원 회귀와 무변경/예외/timeout 오인 거절 엔진 회귀를 연결했다. 이 판정은 해당 UI 경계 대표 결함이며 모든 단언 또는 제품 DB/권한/원자성 source mutant 탐지 범위를 주장하지 않는다. 소스1 소스2
10. 성공·실패의 자원 정리	P	이 CASE의 owned-cleanup이 completed=true이고 모든 context/control/route 자원이 settled/pass다. 실제 page close와 그 뒤 observer disposal/남은 owned listener0을 확인했다. 같은 CASE afterEach 또는 같은 spec의 공유 afterAll이 완료돼 계정·cron 정리 경로도 끝났다. 공유 afterAll은 마지막 CASE stream에 기록된 동일 공유fixture hook을 인용하며 다른 CASE의 본문을 근거로 쓰지 않았다. 실제 기본/수동 context의 본문 실패 경로 및 close/acquire 실패 보존 회귀도 연결했다. 종료 시 역사적 pending 요청은 pageClosed와 구별해 보존하며 정상 응답 완료로 바꾸지 않았다. 소스1 소스2
11. 준비+본문 60초	P	해당 native test의 effective timeout은60000ms이고 최초 시도 duration은21228ms로 개별 준비+본문 60초 한도 안에 끝났다. 공유 beforeAll과 teardown은 별도 hook 예산으로 구분했다. 동작별10초는 현재 소스 기준12 및 별도 bounded-wait 회귀로 확인하며 이 총시간만으로 대체하지 않는다. 소스1 소스2
12. 동작·조건 대기 10초	P	클릭·이동·expect 설정 최대10초, viewportReadiness의 폰트·유한 애니메이션·기하 안정화 한 poll, 수동 도착/완료 lazyConditionWait의 첫 await부터10초와 timer 취소를 확인했다. 지연 응답 route.fetch도10초이며 공유 beforeAll의 별도 예산과 CASE 개별 준비를 구분한다. 소스1 소스2
13. CASE 전체 재시도 0	P	config retries0이며 CASE/file override로전체CASE재시도를켜지않는다. reporter는result.retry!==0을거절한다.같은조건의한정poll/제품의사용자재조회는자동CASE재시도가아니다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정본 viewport22/117checkpoint/22control이 누락 없이 선택되고 각 required reporter와 통합 e2e-evidence 단계가 local-1788983964771-26036에서 pass했다. 이 CASE의 실제 retry0·빈 skip/fixme annotations·expectedStatus passed를 대조했고 재시도/예상실패/누락을 거절하는 집행 회귀도 확인했다. 이는 승인된 browser+viewport 부분 실행의 실제 필수 gate 증거이며 full CI·hosted 승격 완료로 확대 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	정확히1개 진단 attachment의 CASE title/정확SHA/run/attempt/project/locale/timezone/start/end를 해당 결과와 대조했다. 실제 CDP document/loader 세대, request/protocol ID·method/path/status/terminal, control 정상·주입·negative·복원 시각과 문서 연결, close 이후 listener 정리 기록을 확인했다. 보류 요청은 같은 실제 request/document와 phase로 연결됐다. 이 정상 실행의 firstFailure/cleanupFailure는 null이며 이를 실패 경로 증명으로 쓰지 않는다. 현재 SHA에서 실제 viewport reload/hold/first-failure, teardown 중단의 조기 진단 보존, 민감값 제거 회귀를 별도 연결했다. 소스1 소스2

</details>

<a id="case-72"></a> <details><summary>그룹장 이름 저장·공지 두 개 작성은 새로고침 뒤 라운지와 지난 공지에 유지된다 — 그룹장 이름 저장·공지 두 개 작성은 새로고침 뒤 라운지와 지난 공지에 유지된다 (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	실제 입력·행동·단언으로 목적을 확정했다: 그룹장이 그룹명을 변경하고 공지2개를 작성한 뒤 RPC 재조회와 새로고침한 지난 공지 목록에서 유지·순서를 확인한다. 검증 계층: 실제 두 계정·그룹 write/read RPC와 앱 UI. 검사하는 이름은 그룹명이며 owner 프로필 이름이 아니다. 원래 제목의 이름은 코드의 그룹명 textbox/저장 RPC/재진입 단언을 근거로 그룹명 변경을 뜻한다고 감사 범위에 명시한다. owner 프로필 이름 검사로 확대하지 않는다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	시작 입력의 소스 근거: 각 CASE마다 새 owner/member 두 계정과 초대1개가 포함된 별도 그룹을 준비한다. 고정 업무일과 ko-KR/Asia-Seoul을 명시한다. 날짜는 명시된 geometry/feature fixture 입력이며 난수UUID는 계정·mutation 격리용이다. 실제 새 실행 환경 일치 증거는 별도 runtime 항목으로 남긴다. 소스1 소스2
3. 독립 실행	P	일회용 계정과 CASE별 새 context/page, serial 실행 및 격리된 cron scope를 확인했다. 그룹 각 test.beforeEach가 owner/member 계정을 만들고 enter(page, account)가 account.user.id를 전달한다. viewportStats의 호환 export는 drainOwnerStats와 동일 구현이다. owner의 requested_version을 읽어 현재 게시 세대 및 해당 owner active run 완료로 종료하며 다른 owner의 전역 pending0을 조건으로 삼지 않는다. 0/no-state는 같은 owner의 job/run 부재만 확인한다. 이전 호출 범위 공백은 소스로 해소됐고 실제 정리완료는 기준10에서 별도 U다. 소스1 소스2
4. 상태·사건에 따른 순서	P	상태·사건으로 순서 제어: 실제 그룹명 저장/공지 등록 버튼을 사용하고 RPC에 반영된 이름·공지2개를 확인한다. 필요한 response/visible/배치정착을 기다리며 고정 sleep·networkidle만으로 준비를 판정하지 않는다. 단일 조건 대기는 lazyConditionWait와 viewportReadiness의 10초 경계로 제어한다. 개별 통계 준비는 해당 owner의 실제 세대를 읽어 단일10초 deadline으로 완료시키는 경로로 연결됐다. 응답 주입 CASE는 실제 현재 문서의 요청 ID와 주입 구간을 별도 기록한다. 소스1 소스2
5. 독립적인 정답	P	독립 기대값의 실제 근거: 그룹명과 두 공지 원문은 테스트 입력 상수이며 RPC의 배열 전체를 최신→이전 순서의 고정 문자열 배열과 비교한다. 화면 원문 또한 같은 입력을 정답으로 사용한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	그룹 이름 및 서로 다른 공지 두 개를 실제 저장·조회하고 새 문서에서도 같은 이름과 공지 순서를 확인했다. local-1788983964771-26036의 해당 CASE checkpoint 3개와 실제 단언 위치/종료를 원래 소스 조건에 대조했다. 실제 context/document와 정상 reader 값도 함께 확인했다. 소스1 소스2
7. 경계와 금지된 부작용	P	해당 목적의 경계·금지결과: 공지 1개가 아니라2개를 저장해 이전 공지 유실·순서·중복을 전체 RPC 배열로 확인하고 재진입 때 두 원문을 모두 확인한다. 다른 계정 변경권한 거절은 이 owner 저장 CASE의 목적이 아니다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	정본의 3개 필수 checkpoint가 정확히 한 번씩 완료됐고 그 안의 실제 단언 19개가 끝났다. 해당 CASE는 firstAttempt=true이며 missing/duplicate/swallowed/unfinished 오류가 없다. 실제 Playwright 우회·미완료 거절 및 성공 poll 내부 샘플 구분 회귀를 별도 연결했다. 단언 개수만으로 목적을 승인하지 않고 기준6의 실제 상황과 원래 단언 소스에 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	viewport-group-prior-notice-retained가 'group name and notices survive reload'에서 실제 변경1회를 기록했다. 동일 reader/comparator의 정상 true → 결함 false(불일치) → 복원 true(정상 재일치)를 확인했다. 재진입한 지난 공지 목록의 실제 text node에서 이전 공지 원문을 잘못된 원문으로 바꾸고 같은 text reader의 includes 판정을 검사한다. 이전 공지의 표시 유실을 대표한다. DB 공지를 삭제하거나 서버 저장 실패를 허용한 mutant는 아니다. 현재 SHA의 실제 DOM/CSS mutation·복원 회귀와 무변경/예외/timeout 오인 거절 엔진 회귀를 연결했다. 이 판정은 해당 UI 경계 대표 결함이며 모든 단언 또는 제품 DB/권한/원자성 source mutant 탐지 범위를 주장하지 않는다. 소스1 소스2
10. 성공·실패의 자원 정리	P	이 CASE의 owned-cleanup이 completed=true이고 모든 context/control/route 자원이 settled/pass다. 실제 page close와 그 뒤 observer disposal/남은 owned listener0을 확인했다. 같은 CASE afterEach 또는 같은 spec의 공유 afterAll이 완료돼 계정·cron 정리 경로도 끝났다. 공유 afterAll은 마지막 CASE stream에 기록된 동일 공유fixture hook을 인용하며 다른 CASE의 본문을 근거로 쓰지 않았다. 실제 기본/수동 context의 본문 실패 경로 및 close/acquire 실패 보존 회귀도 연결했다. 종료 시 역사적 pending 요청은 pageClosed와 구별해 보존하며 정상 응답 완료로 바꾸지 않았다. 소스1 소스2
11. 준비+본문 60초	P	해당 native test의 effective timeout은60000ms이고 최초 시도 duration은4656ms로 개별 준비+본문 60초 한도 안에 끝났다. 공유 beforeAll과 teardown은 별도 hook 예산으로 구분했다. 동작별10초는 현재 소스 기준12 및 별도 bounded-wait 회귀로 확인하며 이 총시간만으로 대체하지 않는다. 소스1 소스2
12. 동작·조건 대기 10초	P	클릭·이동·expect 설정 최대10초, viewportReadiness의 폰트·유한 애니메이션·기하 안정화 한 poll, 수동 도착/완료 lazyConditionWait의 첫 await부터10초와 timer 취소를 확인했다. 지연 응답 route.fetch도10초이며 공유 beforeAll의 별도 예산과 CASE 개별 준비를 구분한다. 해당 개별 준비의 옛 기본120초 drain은 제거됐다. ownerStats는 최초 세대 조회부터 하나의10초 AbortController deadline을 시작하고 createStatsDrainer에 ownerId/requiredVersion/caseTimeoutMs와 남은timeout·signal을 전달한다. 각 SQL 및 polling에 남은 시간을 사용하고 취소 시 실제 세션 close 완료 후 실패한다. no-state/0도 같은 deadline에서 해당 owner job/run 부재를 확인한다. 소스1 소스2
13. CASE 전체 재시도 0	P	config retries0이며 CASE/file override로전체CASE재시도를켜지않는다. reporter는result.retry!==0을거절한다.같은조건의한정poll/제품의사용자재조회는자동CASE재시도가아니다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정본 viewport22/117checkpoint/22control이 누락 없이 선택되고 각 required reporter와 통합 e2e-evidence 단계가 local-1788983964771-26036에서 pass했다. 이 CASE의 실제 retry0·빈 skip/fixme annotations·expectedStatus passed를 대조했고 재시도/예상실패/누락을 거절하는 집행 회귀도 확인했다. 이는 승인된 browser+viewport 부분 실행의 실제 필수 gate 증거이며 full CI·hosted 승격 완료로 확대 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	정확히1개 진단 attachment의 CASE title/정확SHA/run/attempt/project/locale/timezone/start/end를 해당 결과와 대조했다. 실제 CDP document/loader 세대, request/protocol ID·method/path/status/terminal, control 정상·주입·negative·복원 시각과 문서 연결, close 이후 listener 정리 기록을 확인했다. 보류 요청은 같은 실제 request/document와 phase로 연결됐다. 이 정상 실행의 firstFailure/cleanupFailure는 null이며 이를 실패 경로 증명으로 쓰지 않는다. 현재 SHA에서 실제 viewport reload/hold/first-failure, teardown 중단의 조기 진단 보존, 민감값 제거 회귀를 별도 연결했다. 소스1 소스2

</details>

<a id="case-73"></a> <details><summary>워드마크에서 초대를 수락하고 실제 팔로우 알림 읽음은 새로고침 뒤 유지된다 — 워드마크에서 초대를 수락하고 실제 팔로우 알림 읽음은 새로고침 뒤 유지된다 (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	실제 입력·행동·단언으로 목적을 확정했다: 멤버가 초대를 수락하고 실제 팔로우 알림을 읽은 뒤 서버 read_at와 새로고침 UI에 읽음 상태가 유지되는지 확인한다. 검증 계층: 실제 그룹 초대·가입 RPC, 실제 follow로 만든 notification, 읽음 RPC/UI. 소셜 제공자 로그인 전체는 범위 밖이다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	시작 입력의 소스 근거: 새 owner/member·그룹 초대를 만들고 owner→member 팔로우를 DB에 삽입한다. 합성 notification payload가 아니라 실제 생성 경로를 사용한다. 날짜는 명시된 geometry/feature fixture 입력이며 난수UUID는 계정·mutation 격리용이다. 실제 새 실행 환경 일치 증거는 별도 runtime 항목으로 남긴다. 소스1 소스2
3. 독립 실행	P	일회용 계정과 CASE별 새 context/page, serial 실행 및 격리된 cron scope를 확인했다. 그룹 각 test.beforeEach가 owner/member 계정을 만들고 enter(page, account)가 account.user.id를 전달한다. viewportStats의 호환 export는 drainOwnerStats와 동일 구현이다. owner의 requested_version을 읽어 현재 게시 세대 및 해당 owner active run 완료로 종료하며 다른 owner의 전역 pending0을 조건으로 삼지 않는다. 0/no-state는 같은 owner의 job/run 부재만 확인한다. 이전 호출 범위 공백은 소스로 해소됐고 실제 정리완료는 기준10에서 별도 U다. 소스1 소스2
4. 상태·사건에 따른 순서	P	상태·사건으로 순서 제어: 실제 초대행과 unread follow행이 있는 것을 먼저 확인하고 수락/모두읽음을 실행한다. 필요한 response/visible/배치정착을 기다리며 고정 sleep·networkidle만으로 준비를 판정하지 않는다. 단일 조건 대기는 lazyConditionWait와 viewportReadiness의 10초 경계로 제어한다. 개별 통계 준비는 해당 owner의 실제 세대를 읽어 단일10초 deadline으로 완료시키는 경로로 연결됐다. 응답 주입 CASE는 실제 현재 문서의 요청 ID와 주입 구간을 별도 기록한다. 소스1 소스2
5. 독립적인 정답	P	독립 기대값의 실제 근거: 초대수락 뒤 지정 groupId membership=true, 해당 friend 알림 read_at 존재, 미읽음행0, 재진입 뒤 초대수락버튼0이라는 입력/요구 기반 정답이다. 소스1 소스2
6. 검사 상황의 실제 발생	P	실제 초대 수락·팔로우 알림 읽음과 새 문서에서 읽음 상태 유지를 확인했다. local-1788983964771-26036의 해당 CASE checkpoint 3개와 실제 단언 위치/종료를 원래 소스 조건에 대조했다. 실제 context/document와 정상 reader 값도 함께 확인했다. 소스1 소스2
7. 경계와 금지된 부작용	P	해당 목적의 경계·금지결과: 수락한 초대가 다시 뜨지 않음과 읽음 상태가 재진입으로 되돌아가지 않음을 확인한다. 권한 경계를 종합검사하거나 전체 알림 보존·중복 방지를 주장하지 않는다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	정본의 3개 필수 checkpoint가 정확히 한 번씩 완료됐고 그 안의 실제 단언 18개가 끝났다. 해당 CASE는 firstAttempt=true이며 missing/duplicate/swallowed/unfinished 오류가 없다. 실제 Playwright 우회·미완료 거절 및 성공 poll 내부 샘플 구분 회귀를 별도 연결했다. 단언 개수만으로 목적을 승인하지 않고 기준6의 실제 상황과 원래 단언 소스에 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	viewport-notification-read-state-retained가 'read state survives reload'에서 실제 변경1회를 기록했다. 동일 reader/comparator의 정상 0 → 결함 1(불일치) → 복원 0(정상 재일치)를 확인했다. 이미 읽은 실제 follow행에 unread class를 붙이고 동일 unread locator.count()가 기대0과 달라지는지 검사한다. 재진입 UI의 unread 회귀를 대표한다. 서버 read_at 자체를 변조한 mutation은 아니다. 현재 SHA의 실제 DOM/CSS mutation·복원 회귀와 무변경/예외/timeout 오인 거절 엔진 회귀를 연결했다. 이 판정은 해당 UI 경계 대표 결함이며 모든 단언 또는 제품 DB/권한/원자성 source mutant 탐지 범위를 주장하지 않는다. 소스1 소스2
10. 성공·실패의 자원 정리	P	이 CASE의 owned-cleanup이 completed=true이고 모든 context/control/route 자원이 settled/pass다. 실제 page close와 그 뒤 observer disposal/남은 owned listener0을 확인했다. 같은 CASE afterEach 또는 같은 spec의 공유 afterAll이 완료돼 계정·cron 정리 경로도 끝났다. 공유 afterAll은 마지막 CASE stream에 기록된 동일 공유fixture hook을 인용하며 다른 CASE의 본문을 근거로 쓰지 않았다. 실제 기본/수동 context의 본문 실패 경로 및 close/acquire 실패 보존 회귀도 연결했다. 종료 시 역사적 pending 요청은 pageClosed와 구별해 보존하며 정상 응답 완료로 바꾸지 않았다. 소스1 소스2
11. 준비+본문 60초	P	해당 native test의 effective timeout은60000ms이고 최초 시도 duration은9765ms로 개별 준비+본문 60초 한도 안에 끝났다. 공유 beforeAll과 teardown은 별도 hook 예산으로 구분했다. 동작별10초는 현재 소스 기준12 및 별도 bounded-wait 회귀로 확인하며 이 총시간만으로 대체하지 않는다. 소스1 소스2
12. 동작·조건 대기 10초	P	클릭·이동·expect 설정 최대10초, viewportReadiness의 폰트·유한 애니메이션·기하 안정화 한 poll, 수동 도착/완료 lazyConditionWait의 첫 await부터10초와 timer 취소를 확인했다. 지연 응답 route.fetch도10초이며 공유 beforeAll의 별도 예산과 CASE 개별 준비를 구분한다. 해당 개별 준비의 옛 기본120초 drain은 제거됐다. ownerStats는 최초 세대 조회부터 하나의10초 AbortController deadline을 시작하고 createStatsDrainer에 ownerId/requiredVersion/caseTimeoutMs와 남은timeout·signal을 전달한다. 각 SQL 및 polling에 남은 시간을 사용하고 취소 시 실제 세션 close 완료 후 실패한다. no-state/0도 같은 deadline에서 해당 owner job/run 부재를 확인한다. 소스1 소스2
13. CASE 전체 재시도 0	P	config retries0이며 CASE/file override로전체CASE재시도를켜지않는다. reporter는result.retry!==0을거절한다.같은조건의한정poll/제품의사용자재조회는자동CASE재시도가아니다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정본 viewport22/117checkpoint/22control이 누락 없이 선택되고 각 required reporter와 통합 e2e-evidence 단계가 local-1788983964771-26036에서 pass했다. 이 CASE의 실제 retry0·빈 skip/fixme annotations·expectedStatus passed를 대조했고 재시도/예상실패/누락을 거절하는 집행 회귀도 확인했다. 이는 승인된 browser+viewport 부분 실행의 실제 필수 gate 증거이며 full CI·hosted 승격 완료로 확대 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	정확히1개 진단 attachment의 CASE title/정확SHA/run/attempt/project/locale/timezone/start/end를 해당 결과와 대조했다. 실제 CDP document/loader 세대, request/protocol ID·method/path/status/terminal, control 정상·주입·negative·복원 시각과 문서 연결, close 이후 listener 정리 기록을 확인했다. 보류 요청은 같은 실제 request/document와 phase로 연결됐다. 이 정상 실행의 firstFailure/cleanupFailure는 null이며 이를 실패 경로 증명으로 쓰지 않는다. 현재 SHA에서 실제 viewport reload/hold/first-failure, teardown 중단의 조기 진단 보존, 민감값 제거 회귀를 별도 연결했다. 소스1 소스2

</details>

<a id="case-74"></a> <details><summary>댓글 알림은 첫 피드 페이지 밖 내 운동 한 개를 실제 조회하고 올바른 댓글 시트를 연다 — 댓글 알림은 첫 피드 페이지 밖 내 운동 한 개를 실제 조회하고 올바른 댓글 시트를 연다 (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	실제 입력·행동·단언으로 목적을 확정했다: 첫 피드20개 밖의 오래된 본인 세션을 댓글 알림으로 직접 조회하여 정확한 본문·댓글 시트를 열고 read_at을 저장하는지 확인한다. 검증 계층: 실제26세션·다른 계정 댓글 생성, detail RPC 요청 identity, 타깃 피드/댓글 UI와 notification readback. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	시작 입력의 소스 근거: 별도 두 계정·follow 관계, 2024대상1개와 2026최신25개를 만든다. 업무일2026-09-08로 입력 날짜 간 순서가 명시되며 영원히 과거인 연도를 전제한 런타임조회가 아니다. 날짜는 명시된 geometry/feature fixture 입력이며 난수UUID는 계정·mutation 격리용이다. 실제 새 실행 환경 일치 증거는 별도 runtime 항목으로 남긴다. 소스1 소스2
3. 독립 실행	P	일회용 계정과 CASE별 새 context/page, serial 실행 및 격리된 cron scope를 확인했다. 그룹 각 test.beforeEach가 owner/member 계정을 만들고 enter(page, account)가 account.user.id를 전달한다. viewportStats의 호환 export는 drainOwnerStats와 동일 구현이다. owner의 requested_version을 읽어 현재 게시 세대 및 해당 owner active run 완료로 종료하며 다른 owner의 전역 pending0을 조건으로 삼지 않는다. 0/no-state는 같은 owner의 job/run 부재만 확인한다. 이전 호출 범위 공백은 소스로 해소됐고 실제 정리완료는 기준10에서 별도 U다. 소스1 소스2
4. 상태·사건에 따른 순서	P	상태·사건으로 순서 제어: 초기 target 부재 및 실제 get_session_detail의 p_session_id를 관측하고 해당 요청 성공 뒤 화면을 판정한다. 필요한 response/visible/배치정착을 기다리며 고정 sleep·networkidle만으로 준비를 판정하지 않는다. 단일 조건 대기는 lazyConditionWait와 viewportReadiness의 10초 경계로 제어한다. 개별 통계 준비는 해당 owner의 실제 세대를 읽어 단일10초 deadline으로 완료시키는 경로로 연결됐다. 응답 주입 CASE는 실제 현재 문서의 요청 ID와 주입 구간을 별도 기록한다. 소스1 소스2
5. 독립적인 정답	P	독립 기대값의 실제 근거: 입력한 sessionId/title/note/comment 문자열을 정답으로 하고 detail RPC가 정확한 sessionId로 요청됐는지 확인한다. 타깃이 처음에는 피드에 없어야 한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	목표 운동이 첫 피드 페이지 밖에 있음을 먼저 확인하고 알림으로 정확한 운동·댓글을 연 뒤 읽음 receipt를 확인했다. local-1788983964771-26036의 해당 CASE checkpoint 3개와 실제 단언 위치/종료를 원래 소스 조건에 대조했다. 실제 context/document와 정상 reader 값도 함께 확인했다. 소스1 소스2
7. 경계와 금지된 부작용	P	해당 목적의 경계·금지결과: 첫 페이지 밖 경계를 fixture26개와 target count0으로 확인한다. 알림 클릭 뒤 다른 운동의 본문/댓글이 아닌 정해진 입력과 일치하고 알림 read_at이 저장되는지 확인한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	정본의 3개 필수 checkpoint가 정확히 한 번씩 완료됐고 그 안의 실제 단언 14개가 끝났다. 해당 CASE는 firstAttempt=true이며 missing/duplicate/swallowed/unfinished 오류가 없다. 실제 Playwright 우회·미완료 거절 및 성공 poll 내부 샘플 구분 회귀를 별도 연결했다. 단언 개수만으로 목적을 승인하지 않고 기준6의 실제 상황과 원래 단언 소스에 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	viewport-notification-exact-comment가 'notification opens the exact session and comment'에서 실제 변경1회를 기록했다. 동일 reader/comparator의 정상 true → 결함 false(불일치) → 복원 true(정상 재일치)를 확인했다. 실제 댓글 시트의 대상 댓글 text node를 다른 운동의 댓글 문자열로 바꿔 동일 reader.includes 목표 판정이 깨지는지 확인한다. 잘못된 댓글 표시를 대표한다. 서버 조회 권한·중복조회·DB 저장 원자성 mutation을 수행한 것은 아니다. 현재 SHA의 실제 DOM/CSS mutation·복원 회귀와 무변경/예외/timeout 오인 거절 엔진 회귀를 연결했다. 이 판정은 해당 UI 경계 대표 결함이며 모든 단언 또는 제품 DB/권한/원자성 source mutant 탐지 범위를 주장하지 않는다. 소스1 소스2
10. 성공·실패의 자원 정리	P	이 CASE의 owned-cleanup이 completed=true이고 모든 context/control/route 자원이 settled/pass다. 실제 page close와 그 뒤 observer disposal/남은 owned listener0을 확인했다. 같은 CASE afterEach 또는 같은 spec의 공유 afterAll이 완료돼 계정·cron 정리 경로도 끝났다. 공유 afterAll은 마지막 CASE stream에 기록된 동일 공유fixture hook을 인용하며 다른 CASE의 본문을 근거로 쓰지 않았다. 실제 기본/수동 context의 본문 실패 경로 및 close/acquire 실패 보존 회귀도 연결했다. 종료 시 역사적 pending 요청은 pageClosed와 구별해 보존하며 정상 응답 완료로 바꾸지 않았다. 소스1 소스2
11. 준비+본문 60초	P	해당 native test의 effective timeout은60000ms이고 최초 시도 duration은4515ms로 개별 준비+본문 60초 한도 안에 끝났다. 공유 beforeAll과 teardown은 별도 hook 예산으로 구분했다. 동작별10초는 현재 소스 기준12 및 별도 bounded-wait 회귀로 확인하며 이 총시간만으로 대체하지 않는다. 소스1 소스2
12. 동작·조건 대기 10초	P	클릭·이동·expect 설정 최대10초, viewportReadiness의 폰트·유한 애니메이션·기하 안정화 한 poll, 수동 도착/완료 lazyConditionWait의 첫 await부터10초와 timer 취소를 확인했다. 지연 응답 route.fetch도10초이며 공유 beforeAll의 별도 예산과 CASE 개별 준비를 구분한다. 해당 개별 준비의 옛 기본120초 drain은 제거됐다. ownerStats는 최초 세대 조회부터 하나의10초 AbortController deadline을 시작하고 createStatsDrainer에 ownerId/requiredVersion/caseTimeoutMs와 남은timeout·signal을 전달한다. 각 SQL 및 polling에 남은 시간을 사용하고 취소 시 실제 세션 close 완료 후 실패한다. no-state/0도 같은 deadline에서 해당 owner job/run 부재를 확인한다. 소스1 소스2
13. CASE 전체 재시도 0	P	config retries0이며 CASE/file override로전체CASE재시도를켜지않는다. reporter는result.retry!==0을거절한다.같은조건의한정poll/제품의사용자재조회는자동CASE재시도가아니다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정본 viewport22/117checkpoint/22control이 누락 없이 선택되고 각 required reporter와 통합 e2e-evidence 단계가 local-1788983964771-26036에서 pass했다. 이 CASE의 실제 retry0·빈 skip/fixme annotations·expectedStatus passed를 대조했고 재시도/예상실패/누락을 거절하는 집행 회귀도 확인했다. 이는 승인된 browser+viewport 부분 실행의 실제 필수 gate 증거이며 full CI·hosted 승격 완료로 확대 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	정확히1개 진단 attachment의 CASE title/정확SHA/run/attempt/project/locale/timezone/start/end를 해당 결과와 대조했다. 실제 CDP document/loader 세대, request/protocol ID·method/path/status/terminal, control 정상·주입·negative·복원 시각과 문서 연결, close 이후 listener 정리 기록을 확인했다. 보류 요청은 같은 실제 request/document와 phase로 연결됐다. 이 정상 실행의 firstFailure/cleanupFailure는 null이며 이를 실패 경로 증명으로 쓰지 않는다. 현재 SHA에서 실제 viewport reload/hold/first-failure, teardown 중단의 조기 진단 보존, 민감값 제거 회귀를 별도 연결했다. 소스1 소스2

</details>

<a id="case-75"></a> <details><summary>아이언맨·기능성 트레이너 선택을 저장하고 새로고침 뒤 현재 카드·홈 직업명이 유지된다 — 아이언맨·기능성 트레이너 선택을 저장하고 새로고침 뒤 현재 카드·홈 직업명이 유지된다 (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	실제 입력·행동·단언으로 목적을 확정했다: ironman/functional 두 직업 선택의 저장·서버값·재진입 카드·홈 직업명과 정확한 write2개를 확인한다. 검증 계층: 실제 profile update RPC·profiles readback와 reload UI. 레벨/기록 등급 불변의 전 계층 검증을 주장하지 않는다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	시작 입력의 소스 근거: CASE마다 새 계정·profile/body metric·통계 fixture를 만들고 업무일2026-09-08 및390x844 context를 명시한다. 날짜는 명시된 geometry/feature fixture 입력이며 난수UUID는 계정·mutation 격리용이다. 실제 새 실행 환경 일치 증거는 별도 runtime 항목으로 남긴다. 소스1 소스2
3. 독립 실행	P	일회용 계정과 CASE별 새 context/page, serial 실행 및 격리된 cron scope를 확인했다. 프로필 각 beforeEach가 계정을 만들고 준비 호출에 user.id를 전달한다. viewportStats의 호환 export는 drainOwnerStats와 동일 구현이다. owner의 requested_version을 읽어 현재 게시 세대 및 해당 owner active run 완료로 종료하며 다른 owner의 전역 pending0을 조건으로 삼지 않는다. 0/no-state는 같은 owner의 job/run 부재만 확인한다. 이전 호출 범위 공백은 소스로 해소됐고 실제 정리완료는 기준10에서 별도 U다. 소스1 소스2
4. 상태·사건에 따른 순서	P	상태·사건으로 순서 제어: 실제 저장 버튼·HTTP response 성공·DB값 poll·reload를 순서대로 확인한다. 필요한 response/visible/배치정착을 기다리며 고정 sleep·networkidle만으로 준비를 판정하지 않는다. 단일 조건 대기는 lazyConditionWait와 viewportReadiness의 10초 경계로 제어한다. 개별 통계 준비는 해당 owner의 실제 세대를 읽어 단일10초 deadline으로 완료시키는 경로로 연결됐다. 응답 주입 CASE는 실제 현재 문서의 요청 ID와 주입 구간을 별도 기록한다. 소스1 소스2
5. 독립적인 정답	P	독립 기대값의 실제 근거: id/name 고정 입력쌍, profiles.primary_training_style, aria-checked=true/현재, write payload 정확2개를 독립 기대값으로 사용한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	아이언맨/기능성 선택의 실제 저장과 각 reload 후 현재 카드/직업명 및 정확한 쓰기 횟수를 확인했다. local-1788983964771-26036의 해당 CASE checkpoint 3개와 실제 단언 위치/종료를 원래 소스 조건에 대조했다. 실제 context/document와 정상 reader 값도 함께 확인했다. 소스1 소스2
7. 경계와 금지된 부작용	P	해당 목적의 경계·금지결과: 두 새 선택의 저장과 각각의 reload 후 상태를 검사하며 write 전체배열로 중복/누락/불필요한 필드 변경을 확인한다. 확인창의 등급유지 문구(:111)는 실제 등급값 불변 증거가 아니다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	정본의 3개 필수 checkpoint가 정확히 한 번씩 완료됐고 그 안의 실제 단언 41개가 끝났다. 해당 CASE는 firstAttempt=true이며 missing/duplicate/swallowed/unfinished 오류가 없다. 실제 Playwright 우회·미완료 거절 및 성공 poll 내부 샘플 구분 회귀를 별도 연결했다. 단언 개수만으로 목적을 승인하지 않고 기준6의 실제 상황과 원래 단언 소스에 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	viewport-training-style-restored-selection가 'training style functional persisted and restored'에서 실제 변경1회를 기록했다. 동일 reader/comparator의 정상 "true" → 결함 "false"(불일치) → 복원 "true"(정상 재일치)를 확인했다. 재진입한 functional 카드의 aria-checked를false로 바꾸고 동일 getAttribute reader와 true 기대값을 대조한다. 저장 후 선택 카드 표시의 대표 결함이다. 실제 DB값/기존 등급을 바꾼 제품 mutant는 아니다. 현재 SHA의 실제 DOM/CSS mutation·복원 회귀와 무변경/예외/timeout 오인 거절 엔진 회귀를 연결했다. 이 판정은 해당 UI 경계 대표 결함이며 모든 단언 또는 제품 DB/권한/원자성 source mutant 탐지 범위를 주장하지 않는다. 소스1 소스2
10. 성공·실패의 자원 정리	P	이 CASE의 owned-cleanup이 completed=true이고 모든 context/control/route 자원이 settled/pass다. 실제 page close와 그 뒤 observer disposal/남은 owned listener0을 확인했다. 같은 CASE afterEach 또는 같은 spec의 공유 afterAll이 완료돼 계정·cron 정리 경로도 끝났다. 공유 afterAll은 마지막 CASE stream에 기록된 동일 공유fixture hook을 인용하며 다른 CASE의 본문을 근거로 쓰지 않았다. 실제 기본/수동 context의 본문 실패 경로 및 close/acquire 실패 보존 회귀도 연결했다. 종료 시 역사적 pending 요청은 pageClosed와 구별해 보존하며 정상 응답 완료로 바꾸지 않았다. 소스1 소스2
11. 준비+본문 60초	P	해당 native test의 effective timeout은60000ms이고 최초 시도 duration은10742ms로 개별 준비+본문 60초 한도 안에 끝났다. 공유 beforeAll과 teardown은 별도 hook 예산으로 구분했다. 동작별10초는 현재 소스 기준12 및 별도 bounded-wait 회귀로 확인하며 이 총시간만으로 대체하지 않는다. 소스1 소스2
12. 동작·조건 대기 10초	P	클릭·이동·expect 설정 최대10초, viewportReadiness의 폰트·유한 애니메이션·기하 안정화 한 poll, 수동 도착/완료 lazyConditionWait의 첫 await부터10초와 timer 취소를 확인했다. 지연 응답 route.fetch도10초이며 공유 beforeAll의 별도 예산과 CASE 개별 준비를 구분한다. 해당 개별 준비의 옛 기본120초 drain은 제거됐다. ownerStats는 최초 세대 조회부터 하나의10초 AbortController deadline을 시작하고 createStatsDrainer에 ownerId/requiredVersion/caseTimeoutMs와 남은timeout·signal을 전달한다. 각 SQL 및 polling에 남은 시간을 사용하고 취소 시 실제 세션 close 완료 후 실패한다. no-state/0도 같은 deadline에서 해당 owner job/run 부재를 확인한다. 소스1 소스2
13. CASE 전체 재시도 0	P	config retries0이며 CASE/file override로전체CASE재시도를켜지않는다. reporter는result.retry!==0을거절한다.같은조건의한정poll/제품의사용자재조회는자동CASE재시도가아니다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정본 viewport22/117checkpoint/22control이 누락 없이 선택되고 각 required reporter와 통합 e2e-evidence 단계가 local-1788983964771-26036에서 pass했다. 이 CASE의 실제 retry0·빈 skip/fixme annotations·expectedStatus passed를 대조했고 재시도/예상실패/누락을 거절하는 집행 회귀도 확인했다. 이는 승인된 browser+viewport 부분 실행의 실제 필수 gate 증거이며 full CI·hosted 승격 완료로 확대 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	정확히1개 진단 attachment의 CASE title/정확SHA/run/attempt/project/locale/timezone/start/end를 해당 결과와 대조했다. 실제 CDP document/loader 세대, request/protocol ID·method/path/status/terminal, control 정상·주입·negative·복원 시각과 문서 연결, close 이후 listener 정리 기록을 확인했다. 보류 요청은 같은 실제 request/document와 phase로 연결됐다. 이 정상 실행의 firstFailure/cleanupFailure는 null이며 이를 실패 경로 증명으로 쓰지 않는다. 현재 SHA에서 실제 viewport reload/hold/first-failure, teardown 중단의 조기 진단 보존, 민감값 제거 회귀를 별도 연결했다. 소스1 소스2

</details>

<a id="case-76"></a> <details><summary>성별 해제·키·체중을 한 요청으로 저장하며 pending 중에는 서버 값과 입력을 보존한다 — 성별 해제·키·체중을 한 요청으로 저장하며 pending 중에는 서버 값과 입력을 보존한다 (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	실제 입력·행동·단언으로 목적을 확정했다: 성별 null·키179.5·체중81.2를 하나의 RPC로 저장하고 pending 이전 서버값·불변 근육/체지방·reload 입력을 검사한다. 검증 계층: 실제 요청을 전송 전 보류하는 UI/RPC/DB readback. 성공 경계의 단일요청·전후값 검사이지 DB transaction rollback 실패주입 CASE는 아니다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	시작 입력의 소스 근거: CASE마다 새 계정, 기존 sex=m,height178,weight80,muscle35/bodyfat16/20을 고정 업무일에 준비한다. 날짜는 명시된 geometry/feature fixture 입력이며 난수UUID는 계정·mutation 격리용이다. 실제 새 실행 환경 일치 증거는 별도 runtime 항목으로 남긴다. 소스1 소스2
3. 독립 실행	P	일회용 계정과 CASE별 새 context/page, serial 실행 및 격리된 cron scope를 확인했다. 프로필 각 beforeEach가 계정을 만들고 준비 호출에 user.id를 전달한다. viewportStats의 호환 export는 drainOwnerStats와 동일 구현이다. owner의 requested_version을 읽어 현재 게시 세대 및 해당 owner active run 완료로 종료하며 다른 owner의 전역 pending0을 조건으로 삼지 않는다. 0/no-state는 같은 owner의 job/run 부재만 확인한다. 이전 호출 범위 공백은 소스로 해소됐고 실제 정리완료는 기준10에서 별도 U다. 소스1 소스2
4. 상태·사건에 따른 순서	P	상태·사건으로 순서 제어: 지정 profile RPC의 POST payload를 잡고 arrived 이후에 pending·DB이전값을 확인한다. release 후 response 성공·새 DB값을 검사한다. 필요한 response/visible/배치정착을 기다리며 고정 sleep·networkidle만으로 준비를 판정하지 않는다. 단일 조건 대기는 lazyConditionWait와 viewportReadiness의 10초 경계로 제어한다. 개별 통계 준비는 해당 owner의 실제 세대를 읽어 단일10초 deadline으로 완료시키는 경로로 연결됐다. 응답 주입 CASE는 실제 현재 문서의 요청 ID와 주입 구간을 별도 기록한다. 소스1 소스2
5. 독립적인 정답	P	독립 기대값의 실제 근거: 명시한 이전/다음값과 불변 body metric 필드를 독립 literal로 비교한다. profile/metric 두 테이블 readback을 화면 입력과 비교하되 화면의 계산함수를 기대값으로 쓰지 않는다. 소스1 소스2
6. 검사 상황의 실제 발생	P	실제 profile update 요청을 보류해 입력·서버 원값 보존을 확인한 뒤 해제·원자 저장·reload의 값을 확인했다. local-1788983964771-26036의 해당 CASE checkpoint 3개와 실제 단언 위치/종료를 원래 소스 조건에 대조했다. 실제 주입 이력: profile-body-pending, request 21, document E00599FBC2AA0774511FC73E1AA60EFF, terminal finished. 소스1 소스2
7. 경계와 금지된 부작용	P	해당 목적의 경계·금지결과: 성별해제 null 경계, pending 중 취소/필드 비활성, 이전 DB값 보존, legacy sex write0, 단일 write1, 근육/체지방 불변과 reload가 있다. DB중간실패 rollback을 이 성공 CASE의 증거로 확대하지 않는다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	정본의 3개 필수 checkpoint가 정확히 한 번씩 완료됐고 그 안의 실제 단언 26개가 끝났다. 해당 CASE는 firstAttempt=true이며 missing/duplicate/swallowed/unfinished 오류가 없다. 실제 Playwright 우회·미완료 거절 및 성공 poll 내부 샘플 구분 회귀를 별도 연결했다. 단언 개수만으로 목적을 승인하지 않고 기준6의 실제 상황과 원래 단언 소스에 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	viewport-body-restored-weight가 'body values survive reload'에서 실제 변경1회를 기록했다. 동일 reader/comparator의 정상 "81.2" → 결함 "0"(불일치) → 복원 "81.2"(정상 재일치)를 확인했다. 재진입 후 실제 체중 입력 value를0으로 바꿔 동일 inputValue reader가 저장 기대81.2와 불일치하는지 검사한다. 재진입 입력의 잘못된 체중 표시를 대표한다. DB 원자성·중복 방지 제약을 제거한 mutant 증거는 없다. 현재 SHA의 실제 DOM/CSS mutation·복원 회귀와 무변경/예외/timeout 오인 거절 엔진 회귀를 연결했다. 이 판정은 해당 UI 경계 대표 결함이며 모든 단언 또는 제품 DB/권한/원자성 source mutant 탐지 범위를 주장하지 않는다. 소스1 소스2
10. 성공·실패의 자원 정리	P	이 CASE의 owned-cleanup이 completed=true이고 모든 context/control/route 자원이 settled/pass다. 실제 page close와 그 뒤 observer disposal/남은 owned listener0을 확인했다. 같은 CASE afterEach 또는 같은 spec의 공유 afterAll이 완료돼 계정·cron 정리 경로도 끝났다. 공유 afterAll은 마지막 CASE stream에 기록된 동일 공유fixture hook을 인용하며 다른 CASE의 본문을 근거로 쓰지 않았다. 실제 기본/수동 context의 본문 실패 경로 및 close/acquire 실패 보존 회귀도 연결했다. 종료 시 역사적 pending 요청은 pageClosed와 구별해 보존하며 정상 응답 완료로 바꾸지 않았다. 소스1 소스2
11. 준비+본문 60초	P	해당 native test의 effective timeout은60000ms이고 최초 시도 duration은5281ms로 개별 준비+본문 60초 한도 안에 끝났다. 공유 beforeAll과 teardown은 별도 hook 예산으로 구분했다. 동작별10초는 현재 소스 기준12 및 별도 bounded-wait 회귀로 확인하며 이 총시간만으로 대체하지 않는다. 소스1 소스2
12. 동작·조건 대기 10초	P	클릭·이동·expect 설정 최대10초, viewportReadiness의 폰트·유한 애니메이션·기하 안정화 한 poll, 수동 도착/완료 lazyConditionWait의 첫 await부터10초와 timer 취소를 확인했다. 지연 응답 route.fetch도10초이며 공유 beforeAll의 별도 예산과 CASE 개별 준비를 구분한다. 해당 개별 준비의 옛 기본120초 drain은 제거됐다. ownerStats는 최초 세대 조회부터 하나의10초 AbortController deadline을 시작하고 createStatsDrainer에 ownerId/requiredVersion/caseTimeoutMs와 남은timeout·signal을 전달한다. 각 SQL 및 polling에 남은 시간을 사용하고 취소 시 실제 세션 close 완료 후 실패한다. no-state/0도 같은 deadline에서 해당 owner job/run 부재를 확인한다. 소스1 소스2
13. CASE 전체 재시도 0	P	config retries0이며 CASE/file override로전체CASE재시도를켜지않는다. reporter는result.retry!==0을거절한다.같은조건의한정poll/제품의사용자재조회는자동CASE재시도가아니다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정본 viewport22/117checkpoint/22control이 누락 없이 선택되고 각 required reporter와 통합 e2e-evidence 단계가 local-1788983964771-26036에서 pass했다. 이 CASE의 실제 retry0·빈 skip/fixme annotations·expectedStatus passed를 대조했고 재시도/예상실패/누락을 거절하는 집행 회귀도 확인했다. 이는 승인된 browser+viewport 부분 실행의 실제 필수 gate 증거이며 full CI·hosted 승격 완료로 확대 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	정확히1개 진단 attachment의 CASE title/정확SHA/run/attempt/project/locale/timezone/start/end를 해당 결과와 대조했다. 실제 CDP document/loader 세대, request/protocol ID·method/path/status/terminal, control 정상·주입·negative·복원 시각과 문서 연결, close 이후 listener 정리 기록을 확인했다. 보류 요청은 같은 실제 request/document와 phase로 연결됐다. 이 정상 실행의 firstFailure/cleanupFailure는 null이며 이를 실패 경로 증명으로 쓰지 않는다. 현재 SHA에서 실제 viewport reload/hold/first-failure, teardown 중단의 조기 진단 보존, 민감값 제거 회귀를 별도 연결했다. 소스1 소스2

</details>

<a id="case-77"></a> <details><summary>연간·월간 이동은 선택한 기간만 읽고 실제 10칸 분포 네 종류를 표시한다 — 연간·월간 이동은 선택한 기간만 읽고 실제 10칸 분포 네 종류를 표시한다 (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	실제 입력·행동·단언으로 목적을 확정했다: 연간→현재월→이전월 선택마다 필요한 요청만 발생하고 해당 payload의 지표·4종10bin을 UI에 연결하며 상세 스택 왕복이 기간을 바꾸지 않는지 검사한다. 검증 계층: 실제 report RPC·UI 요청 scope·payload 표시. 통계 SQL 계산 전체의 독립 oracle 검증은 별도 범위다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	시작 입력의 소스 근거: 전용 계정·4일×2종목×3세트로 실제 통계 관측을 준비하고 drain/freshness와 연/9월/8월 RPC의 각10bin·관측합>0·서로 다른volume을 확인한다. DATE2026-09-08과 고정기간 입력을 명시한다. 날짜는 명시된 geometry/feature fixture 입력이며 난수UUID는 계정·mutation 격리용이다. 실제 새 실행 환경 일치 증거는 별도 runtime 항목으로 남긴다. 소스1 소스2
3. 독립 실행	P	전용 일회용 계정과 CASE별 새 context/page를 사용한다. workers1에서만 이 공유 fixture를 실행하며 다른 CASE 결과를 입력으로 쓰지 않는다. DB cron scope는 명시 격리 sandbox를 확인하고 teardown에서 복원한다. 실제 성공/실패 정리 완료는 기준10에서 별도 U다. 소스1 소스2
4. 상태·사건에 따른 순서	P	상태·사건으로 순서 제어: 실제 메뉴·이전기간·하루/세션 링크로 탐색하며 ready화면과 정확한 RPC scope를 확인한다. 필요한 response/visible/배치정착을 기다리며 고정 sleep·networkidle만으로 준비를 판정하지 않는다. 단일 조건 대기는 lazyConditionWait와 viewportReadiness의 10초 경계로 제어한다. 개별 통계 준비는 해당 owner의 실제 세대를 읽어 단일10초 deadline으로 완료시키는 경로로 연결됐다. 응답 주입 CASE는 실제 현재 문서의 요청 ID와 주입 구간을 별도 기록한다. 소스1 소스2
5. 독립적인 정답	P	독립 기대값의 실제 근거: UI 바인딩의 정답은 UI 호출과 별도로 실제 서버에서 조회한 expected payload이다. period/request args와10bin labels는 테스트 고정표이며 volume/RPE 표시를 독립 간단 변환한다. 서버 통계 계산 자체가 맞는지는 이 UI CASE가 보장하는 범위가 아니다. 소스1 소스2
6. 검사 상황의 실제 발생	P	비활성 보고서의 무요청, 연간/현재월/이전월 정확한 요청·별도 서버 payload의 UI 값·네10칸 분포를 확인했다. local-1788983964771-26036의 해당 CASE checkpoint 5개와 실제 단언 위치/종료를 원래 소스 조건에 대조했다. 실제 context/document와 정상 reader 값도 함께 확인했다. 소스1 소스2
7. 경계와 금지된 부작용	P	해당 목적의 경계·금지결과: 비활성 상세요청0, 각단계 정확한 request배열, 10bin4종 라벨·비영 관측색, 세션→하루→리포트 역순 닫힘 및 기간/요청 불변을 검사한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	정본의 5개 필수 checkpoint가 정확히 한 번씩 완료됐고 그 안의 실제 단언 80개가 끝났다. 해당 CASE는 firstAttempt=true이며 missing/duplicate/swallowed/unfinished 오류가 없다. 실제 Playwright 우회·미완료 거절 및 성공 poll 내부 샘플 구분 회귀를 별도 연결했다. 단언 개수만으로 목적을 승인하지 않고 기준6의 실제 상황과 원래 단언 소스에 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	viewport-report-selected-period-label가 'previous month exact data and request'에서 실제 변경1회를 기록했다. 동일 reader/comparator의 정상 "2026년 8월" → 결함 "선택하지 않은 잘못된 기간"(불일치) → 복원 "2026년 8월"(정상 재일치)를 확인했다. 이전월 제목을 잘못된 기간 문자열로 교체하고 동일 innerText.trim reader와 독립 previousMonthLabel을 비교한다. 선택기간 제목 불일치의 대표 DOM 결함이다. 네 histogram 전체의 계산/바인딩 각각을 변조한 증거는 아니다. 현재 SHA의 실제 DOM/CSS mutation·복원 회귀와 무변경/예외/timeout 오인 거절 엔진 회귀를 연결했다. 이 판정은 해당 UI 경계 대표 결함이며 모든 단언 또는 제품 DB/권한/원자성 source mutant 탐지 범위를 주장하지 않는다. 소스1 소스2
10. 성공·실패의 자원 정리	P	이 CASE의 owned-cleanup이 completed=true이고 모든 context/control/route 자원이 settled/pass다. 실제 page close와 그 뒤 observer disposal/남은 owned listener0을 확인했다. 같은 CASE afterEach 또는 같은 spec의 공유 afterAll이 완료돼 계정·cron 정리 경로도 끝났다. 공유 afterAll은 마지막 CASE stream에 기록된 동일 공유fixture hook을 인용하며 다른 CASE의 본문을 근거로 쓰지 않았다. 실제 기본/수동 context의 본문 실패 경로 및 close/acquire 실패 보존 회귀도 연결했다. 종료 시 역사적 pending 요청은 pageClosed와 구별해 보존하며 정상 응답 완료로 바꾸지 않았다. 소스1 소스2
11. 준비+본문 60초	P	해당 native test의 effective timeout은60000ms이고 최초 시도 duration은5048ms로 개별 준비+본문 60초 한도 안에 끝났다. 공유 beforeAll과 teardown은 별도 hook 예산으로 구분했다. 동작별10초는 현재 소스 기준12 및 별도 bounded-wait 회귀로 확인하며 이 총시간만으로 대체하지 않는다. 소스1 소스2
12. 동작·조건 대기 10초	P	클릭·이동·expect 설정 최대10초, viewportReadiness의 폰트·유한 애니메이션·기하 안정화 한 poll, 수동 도착/완료 lazyConditionWait의 첫 await부터10초와 timer 취소를 확인했다. 지연 응답 route.fetch도10초이며 공유 beforeAll의 별도 예산과 CASE 개별 준비를 구분한다. 소스1 소스2
13. CASE 전체 재시도 0	P	config retries0이며 CASE/file override로전체CASE재시도를켜지않는다. reporter는result.retry!==0을거절한다.같은조건의한정poll/제품의사용자재조회는자동CASE재시도가아니다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정본 viewport22/117checkpoint/22control이 누락 없이 선택되고 각 required reporter와 통합 e2e-evidence 단계가 local-1788983964771-26036에서 pass했다. 이 CASE의 실제 retry0·빈 skip/fixme annotations·expectedStatus passed를 대조했고 재시도/예상실패/누락을 거절하는 집행 회귀도 확인했다. 이는 승인된 browser+viewport 부분 실행의 실제 필수 gate 증거이며 full CI·hosted 승격 완료로 확대 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	정확히1개 진단 attachment의 CASE title/정확SHA/run/attempt/project/locale/timezone/start/end를 해당 결과와 대조했다. 실제 CDP document/loader 세대, request/protocol ID·method/path/status/terminal, control 정상·주입·negative·복원 시각과 문서 연결, close 이후 listener 정리 기록을 확인했다. 보류 요청은 같은 실제 request/document와 phase로 연결됐다. 이 정상 실행의 firstFailure/cleanupFailure는 null이며 이를 실패 경로 증명으로 쓰지 않는다. 현재 SHA에서 실제 viewport reload/hold/first-failure, teardown 중단의 조기 진단 보존, 민감값 제거 회귀를 별도 연결했다. 소스1 소스2

</details>

<a id="case-78"></a> <details><summary>먼저 요청한 8월 응답이 늦게 도착해도 새로 선택한 연간 리포트를 덮어쓰지 않는다 — 먼저 요청한 8월 응답이 늦게 도착해도 새로 선택한 연간 리포트를 덮어쓰지 않는다 (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	실제 입력·행동·단언으로 목적을 확정했다: 8월의 실제 서버 응답을 보류한 동안 연간으로 선택을 바꾸고 늦은 응답을 해제해도 연간 scope/지표가 유지되는지 검사한다. 검증 계층: 실제 RPC 결과의 브라우저 전달 지연·취소와 UI stale-response 차단. 서버 원문은 가짜 payload로 대체하지 않는다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	시작 입력의 소스 근거: 전용 계정·4일×2종목×3세트로 실제 통계 관측을 준비하고 drain/freshness와 연/9월/8월 RPC의 각10bin·관측합>0·서로 다른volume을 확인한다. DATE2026-09-08과 고정기간 입력을 명시한다. 날짜는 명시된 geometry/feature fixture 입력이며 난수UUID는 계정·mutation 격리용이다. 실제 새 실행 환경 일치 증거는 별도 runtime 항목으로 남긴다. 소스1 소스2
3. 독립 실행	P	전용 일회용 계정과 CASE별 새 context/page를 사용한다. workers1에서만 이 공유 fixture를 실행하며 다른 CASE 결과를 입력으로 쓰지 않는다. DB cron scope는 명시 격리 sandbox를 확인하고 teardown에서 복원한다. 실제 성공/실패 정리 완료는 기준10에서 별도 U다. 소스1 소스2
4. 상태·사건에 따른 순서	P	상태·사건으로 순서 제어: 정확한 RPC POST의8월 args에 대해서만 route.fetch 결과를 보류하고 heldPayload volume과loading을 단언하며 release/handled를 기다린다. 필요한 response/visible/배치정착을 기다리며 고정 sleep·networkidle만으로 준비를 판정하지 않는다. 단일 조건 대기는 lazyConditionWait와 viewportReadiness의 10초 경계로 제어한다. 개별 통계 준비는 해당 owner의 실제 세대를 읽어 단일10초 deadline으로 완료시키는 경로로 연결됐다. 응답 주입 CASE는 실제 현재 문서의 요청 ID와 주입 구간을 별도 기록한다. 소스1 소스2
5. 독립적인 정답	P	독립 기대값의 실제 근거: UI 바인딩의 정답은 UI 호출과 별도로 실제 서버에서 조회한 expected payload이다. period/request args와10bin labels는 테스트 고정표이며 volume/RPE 표시를 독립 간단 변환한다. 서버 통계 계산 자체가 맞는지는 이 UI CASE가 보장하는 범위가 아니다. 연간과8월 volume이 다름을 사전 단언해 두 선택이 같은 숫자여서 통과하는 경우를 차단한다. 소스1 소스2
6. 검사 상황의 실제 발생	P	서로 다른 연간/8월 volume을 사전 확인하고 실제 8월 upstream 응답을 보류했다. 새 연간 선택으로 옛 Chromium 요청이 abort되는 명시된 stale 차단 경로와 해제 후 연간값 유지를 확인했다. 옛 payload가 JavaScript에 전달됐다고 주장하지 않는다. local-1788983964771-26036의 해당 CASE checkpoint 5개와 실제 단언 위치/종료를 원래 소스 조건에 대조했다. 실제 주입 이력: late-august-report, request 20, document 46BBE71881C3E2498C30783C12B9B753, terminal failed. 소스1 소스2
7. 경계와 금지된 부작용	P	해당 목적의 경계·금지결과: 구 요청 보류/loading·새 연간 선택·해제 후 연간 값/제목/정확3요청을 확인한다. 구 요청 abort도 명시된 정상 차단으로 분류하며 예외는 해당route fulfill의 취소 관련문자열만 허용한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	정본의 5개 필수 checkpoint가 정확히 한 번씩 완료됐고 그 안의 실제 단언 61개가 끝났다. 해당 CASE는 firstAttempt=true이며 missing/duplicate/swallowed/unfinished 오류가 없다. 실제 Playwright 우회·미완료 거절 및 성공 poll 내부 샘플 구분 회귀를 별도 연결했다. 단언 개수만으로 목적을 승인하지 않고 기준6의 실제 상황과 원래 단언 소스에 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	viewport-report-stale-month-cannot-win가 'late month response cannot replace annual data'에서 실제 변경1회를 기록했다. 동일 reader/comparator의 정상 "12,500kg" → 결함 "6,250kg"(불일치) → 복원 "12,500kg"(정상 재일치)를 확인했다. 연간 volume text node를 사전확인한8월 volume으로 바꿔 같은 readViewportText와 volumeDisplay(expected.year) 판정이 깨지는지 검사한다. 이전월 값이 연간 지표를 덮는 표시 경계의 대표 결함이다. 제품의 request-generation guard를 제거한 source mutant는 아니다. 현재 SHA의 실제 DOM/CSS mutation·복원 회귀와 무변경/예외/timeout 오인 거절 엔진 회귀를 연결했다. 이 판정은 해당 UI 경계 대표 결함이며 모든 단언 또는 제품 DB/권한/원자성 source mutant 탐지 범위를 주장하지 않는다. 소스1 소스2
10. 성공·실패의 자원 정리	P	이 CASE의 owned-cleanup이 completed=true이고 모든 context/control/route 자원이 settled/pass다. 실제 page close와 그 뒤 observer disposal/남은 owned listener0을 확인했다. 같은 CASE afterEach 또는 같은 spec의 공유 afterAll이 완료돼 계정·cron 정리 경로도 끝났다. 공유 afterAll은 마지막 CASE stream에 기록된 동일 공유fixture hook을 인용하며 다른 CASE의 본문을 근거로 쓰지 않았다. 실제 기본/수동 context의 본문 실패 경로 및 close/acquire 실패 보존 회귀도 연결했다. 종료 시 역사적 pending 요청은 pageClosed와 구별해 보존하며 정상 응답 완료로 바꾸지 않았다. 소스1 소스2
11. 준비+본문 60초	P	해당 native test의 effective timeout은60000ms이고 최초 시도 duration은4248ms로 개별 준비+본문 60초 한도 안에 끝났다. 공유 beforeAll과 teardown은 별도 hook 예산으로 구분했다. 동작별10초는 현재 소스 기준12 및 별도 bounded-wait 회귀로 확인하며 이 총시간만으로 대체하지 않는다. 소스1 소스2
12. 동작·조건 대기 10초	P	클릭·이동·expect 설정 최대10초, viewportReadiness의 폰트·유한 애니메이션·기하 안정화 한 poll, 수동 도착/완료 lazyConditionWait의 첫 await부터10초와 timer 취소를 확인했다. 지연 응답 route.fetch도10초이며 공유 beforeAll의 별도 예산과 CASE 개별 준비를 구분한다. 소스1 소스2
13. CASE 전체 재시도 0	P	config retries0이며 CASE/file override로전체CASE재시도를켜지않는다. reporter는result.retry!==0을거절한다.같은조건의한정poll/제품의사용자재조회는자동CASE재시도가아니다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정본 viewport22/117checkpoint/22control이 누락 없이 선택되고 각 required reporter와 통합 e2e-evidence 단계가 local-1788983964771-26036에서 pass했다. 이 CASE의 실제 retry0·빈 skip/fixme annotations·expectedStatus passed를 대조했고 재시도/예상실패/누락을 거절하는 집행 회귀도 확인했다. 이는 승인된 browser+viewport 부분 실행의 실제 필수 gate 증거이며 full CI·hosted 승격 완료로 확대 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	정확히1개 진단 attachment의 CASE title/정확SHA/run/attempt/project/locale/timezone/start/end를 해당 결과와 대조했다. 실제 CDP document/loader 세대, request/protocol ID·method/path/status/terminal, control 정상·주입·negative·복원 시각과 문서 연결, close 이후 listener 정리 기록을 확인했다. 보류 요청은 같은 실제 request/document와 phase로 연결됐다. 이 정상 실행의 firstFailure/cleanupFailure는 null이며 이를 실패 경로 증명으로 쓰지 않는다. 현재 SHA에서 실제 viewport reload/hold/first-failure, teardown 중단의 조기 진단 보존, 민감값 제거 회귀를 별도 연결했다. 소스1 소스2

</details>

<a id="case-79"></a> <details><summary>상세 RPC 일시 실패는 로그인 상태를 유지하며 재시도로 실서버 데이터를 복구한다 — 상세 RPC 일시 실패는 로그인 상태를 유지하며 재시도로 실서버 데이터를 복구한다 (P)</summary>

원본 CASE

기준	판정	근거
1. 검증 목적과 범위	P	실제 입력·행동·단언으로 목적을 확정했다: 선언된 report 첫 요청503 실패가 로그인 상태를 무너뜨리지 않고 사용자 재조회1회로 실제 서버 data ready상태를 복구하는지 확인한다. 검증 계층: 첫HTTP응답503 주입, 다음 실제RPC응답/UI. 실제 서버 자체 장애/DB제약 제거의 증거로 보고하지 않는다. 소스1 소스2
2. 재현 가능한 시작 조건과 입력	P	시작 입력의 소스 근거: 전용 계정·4일×2종목×3세트로 실제 통계 관측을 준비하고 drain/freshness와 연/9월/8월 RPC의 각10bin·관측합>0·서로 다른volume을 확인한다. DATE2026-09-08과 고정기간 입력을 명시한다. 날짜는 명시된 geometry/feature fixture 입력이며 난수UUID는 계정·mutation 격리용이다. 실제 새 실행 환경 일치 증거는 별도 runtime 항목으로 남긴다. 소스1 소스2
3. 독립 실행	P	전용 일회용 계정과 CASE별 새 context/page를 사용한다. workers1에서만 이 공유 fixture를 실행하며 다른 CASE 결과를 입력으로 쓰지 않는다. DB cron scope는 명시 격리 sandbox를 확인하고 teardown에서 복원한다. 실제 성공/실패 정리 완료는 기준10에서 별도 U다. 소스1 소스2
4. 상태·사건에 따른 순서	P	상태·사건으로 순서 제어: holdFirstFailure는 지정path/method의 첫요청만 보류·503으로 바꾸며 CASE는 started/loading/error/attempts2를 확인한다. 필요한 response/visible/배치정착을 기다리며 고정 sleep·networkidle만으로 준비를 판정하지 않는다. 단일 조건 대기는 lazyConditionWait와 viewportReadiness의 10초 경계로 제어한다. 개별 통계 준비는 해당 owner의 실제 세대를 읽어 단일10초 deadline으로 완료시키는 경로로 연결됐다. 응답 주입 CASE는 실제 현재 문서의 요청 ID와 주입 구간을 별도 기록한다. 소스1 소스2
5. 독립적인 정답	P	독립 기대값의 실제 근거: UI 바인딩의 정답은 UI 호출과 별도로 실제 서버에서 조회한 expected payload이다. period/request args와10bin labels는 테스트 고정표이며 volume/RPE 표시를 독립 간단 변환한다. 서버 통계 계산 자체가 맞는지는 이 UI CASE가 보장하는 범위가 아니다. 예상 첫응답503과 error/로그인게이트0, 재조회2번째 요청·ready는 독립 상태/횟수 기대값이다. 소스1 소스2
6. 검사 상황의 실제 발생	P	실제 report 요청의 held/loading→선언503/error(로그인 유지)→사용자 재조회1회/실서버 ready 및 정확한 두 요청을 확인했다. local-1788983964771-26036의 해당 CASE checkpoint 4개와 실제 단언 위치/종료를 원래 소스 조건에 대조했다. 실제 주입 이력: report-first-response-failure, request 19, document 58086A043D03F29B92E8BF56130CEFA8, terminal finished. 소스1 소스2
7. 경계와 금지된 부작용	P	해당 목적의 경계·금지결과: pending/loading→error→ready, 로그인게이트 부재, 사용자 재조회 단한번으로 정확2요청, 실제4histogram/지표 복구를 확인한다. 자동CASE retry와 사용자의 다시불러오기는 구분한다. 소스1 소스2
8. 필수 단언과 비동기 완료	P	정본의 4개 필수 checkpoint가 정확히 한 번씩 완료됐고 그 안의 실제 단언 27개가 끝났다. 해당 CASE는 firstAttempt=true이며 missing/duplicate/swallowed/unfinished 오류가 없다. 실제 Playwright 우회·미완료 거절 및 성공 poll 내부 샘플 구분 회귀를 별도 연결했다. 단언 개수만으로 목적을 승인하지 않고 기준6의 실제 상황과 원래 단언 소스에 대조했다. 소스1 소스2
9. 대표 결함 탐지와 공통 도구 검증	P	viewport-report-retry-ready-state가 'report retry restores real data'에서 실제 변경1회를 기록했다. 동일 reader/comparator의 정상 "ready" → 결함 "error"(불일치) → 복원 "ready"(정상 재일치)를 확인했다. 복구한 실제 report root의 data-lg-state를error로 바꿔 정상 단언과 같은 attribute reader/ready 기대값이 거절하는지 확인한다. 재조회 후 오류 상태가 남는 UI 경계 대표 결함이다. 실제 서버 장애나 auth/DB제약을 제거하는 mutation은 아니다. 현재 SHA의 실제 DOM/CSS mutation·복원 회귀와 무변경/예외/timeout 오인 거절 엔진 회귀를 연결했다. 이 판정은 해당 UI 경계 대표 결함이며 모든 단언 또는 제품 DB/권한/원자성 source mutant 탐지 범위를 주장하지 않는다. 소스1 소스2
10. 성공·실패의 자원 정리	P	이 CASE의 owned-cleanup이 completed=true이고 모든 context/control/route 자원이 settled/pass다. 실제 page close와 그 뒤 observer disposal/남은 owned listener0을 확인했다. 같은 CASE afterEach 또는 같은 spec의 공유 afterAll이 완료돼 계정·cron 정리 경로도 끝났다. 공유 afterAll은 마지막 CASE stream에 기록된 동일 공유fixture hook을 인용하며 다른 CASE의 본문을 근거로 쓰지 않았다. 실제 기본/수동 context의 본문 실패 경로 및 close/acquire 실패 보존 회귀도 연결했다. 종료 시 역사적 pending 요청은 pageClosed와 구별해 보존하며 정상 응답 완료로 바꾸지 않았다. 소스1 소스2
11. 준비+본문 60초	P	해당 native test의 effective timeout은60000ms이고 최초 시도 duration은2940ms로 개별 준비+본문 60초 한도 안에 끝났다. 공유 beforeAll과 teardown은 별도 hook 예산으로 구분했다. 동작별10초는 현재 소스 기준12 및 별도 bounded-wait 회귀로 확인하며 이 총시간만으로 대체하지 않는다. 소스1 소스2
12. 동작·조건 대기 10초	P	클릭·이동·expect 설정 최대10초, viewportReadiness의 폰트·유한 애니메이션·기하 안정화 한 poll, 수동 도착/완료 lazyConditionWait의 첫 await부터10초와 timer 취소를 확인했다. 지연 응답 route.fetch도10초이며 공유 beforeAll의 별도 예산과 CASE 개별 준비를 구분한다. 소스1 소스2
13. CASE 전체 재시도 0	P	config retries0이며 CASE/file override로전체CASE재시도를켜지않는다. reporter는result.retry!==0을거절한다.같은조건의한정poll/제품의사용자재조회는자동CASE재시도가아니다. 소스1 소스2
14. 필수 CI의 생략·우회 차단	P	정본 viewport22/117checkpoint/22control이 누락 없이 선택되고 각 required reporter와 통합 e2e-evidence 단계가 local-1788983964771-26036에서 pass했다. 이 CASE의 실제 retry0·빈 skip/fixme annotations·expectedStatus passed를 대조했고 재시도/예상실패/누락을 거절하는 집행 회귀도 확인했다. 이는 승인된 browser+viewport 부분 실행의 실제 필수 gate 증거이며 full CI·hosted 승격 완료로 확대 보고하지 않는다. 소스1 소스2
15. 첫 실패의 재현·진단 증거	P	정확히1개 진단 attachment의 CASE title/정확SHA/run/attempt/project/locale/timezone/start/end를 해당 결과와 대조했다. 실제 CDP document/loader 세대, request/protocol ID·method/path/status/terminal, control 정상·주입·negative·복원 시각과 문서 연결, close 이후 listener 정리 기록을 확인했다. 보류 요청은 같은 실제 request/document와 phase로 연결됐다. 이 정상 실행의 firstFailure/cleanupFailure는 null이며 이를 실패 경로 증명으로 쓰지 않는다. 현재 SHA에서 실제 viewport reload/hold/first-failure, teardown 중단의 조기 진단 보존, 민감값 제거 회귀를 별도 연결했다. 소스1 소스2

</details>

미검증과 적용 상태

CASE056의 기준14는 Barbelic-docs Actions secret BARBELIC_BACKEND_ARTIFACTS_READ_TOKEN 등록 및 필수 hosted 실행 성공 전까지 U다. 이 token은 앱 저장소 한 곳의 Actions 읽기만 허용한다. 로컬 성공·앱 artifact 발행 성공을 hosted 소비 성공으로 대신하지 않는다. 앱 release 통합이나 문서 게시만으로 이 CASE와79건 전체를 승인하지 않는다.

공개 JSON SHA-256: ceb5d541231d61a13ea64f6fcc52e41258c37ecf20a62feaafe44ec5e9a81f56. 원본21MB 감사와 원시 실행 파일의 해시는 JSON에 보존했고, 공개본은 중복 소스 설명을 줄이면서1,185개 판정·관측값·원본 해시를 유지했다.