2026-07-15 실제 actor 테스트 증거

이 페이지는 2026-07-15에 실행한 actor별 브라우저·API 검사를 한곳에서 찾기 위한 인덱스다. 화면이 보였다는 사실과 업무가 끝났다는 주장을 분리한다. 모든 증거는 로컬 실행이며 온라인 배포를 만들거나 stage migration을 적용하지 않았다.

현재 순서·acceptance case·PASS 기준은 Actor A-Z 워크플로우 Acceptance SSOT가 소유한다. 이 페이지는 당시 runtime truth의 역사 증거이며 phase 순서나 완료 판정을 소유하지 않는다.

프로비저널 실제 증거 — A-Z 완료 아님

산모는 draft 생성에서 503, 지점 command board는 권한 수정 뒤 context 부재 404에서 멈췄다. 관리사 일정 조회는 200이지만 결과가 0건이다. 예약 확정, 지점 mutation, 출근, 일일 리포트, 관리사 지급, 지점·본사 정산 완료를 증명하지 않는다.

증거 분류

분류	포함	해석
실제 인증 read	지점 worklist 200, 관리사 일정 200	권한 경계와 현재 runtime 데이터만 증명
실제 실패	산모 draft 503, 지점 command context 503 → 404	fail-closed 상태와 다음 blocker를 증명
mock UI 회귀	기존 산모 10단계 route-mock 실행	채팅 상호작용만 증명; API·DB 성공 근거 아님
제외	fixture 기반 관리자 dashboard, 이름·전화·프로필 식별자가 남은 원본	actual actor 증거로 게시하지 않음

실행 중 상태 전이가 생기지 않은 실패·empty run은 한 프레임을 반복한 가짜 영상으로 만들지 않는다. 실제 순차 단계가 생길 때만 animated WebP를 추가한다.

산모 · current-source draft 생성 실패

실제 stage Supabase 산모 세션을 refresh하고 현재 backend source sidecar에 연결했다. desktop/mobile 모두 POST /customer-reservation-drafts가 503, active card는 0이었다. route mock은 없었다.

desktop · 실제 실패 · 첫 카드 미진입

mobile · 실제 실패 · 첫 카드 미진입

상세 절차와 DB migration 경계는 산모 가족 예약 증거 페이지의 2026-07-15 절, sanitized run summary, supplemental manifest에서 확인한다.

지점 운영자 · worklist read 성공, command context 실패

지점 운영자 직접 API read는 200, 전체 visibility 501건, 첫 page 50건이었다. 같은 route를 산모 actor로 호출하면 403이었다. 브라우저 캡처 시점에는 SSR worklist가 권한 오류로 실패했다. backend 2be847397eed0dcbad10595722f65e6fdfecaa76이 DB permission 호출을 현재 schema에 맞춘 뒤 실패는 404로 좁혀졌고, 이는 선택 행의 operation context가 없다는 뜻이었다. 1c488e80889c73aeba061d700c20278144e69aae이 materializer와 migration을 추가했지만 stage에는 적용하지 않았다.

desktop · 수정 전 실제 실패 화면

mobile · 수정 전 실제 실패 화면

이미지는 원본 실제 브라우저 캡처에서 실패 surface만 crop했다. fixture 관리자 화면과 식별자·이름·전화가 들어갈 수 있는 영역은 포함하지 않았다. 숫자·수정 lineage는 sanitized run summary와 supplemental manifest에서 대조한다.

성공 조건은 stage와 분리된 Supabase에 materialization migration을 적용하고, 같은 test-owned 예약을 지점 운영자가 선택해 허용 command, mutation, conflict, idempotent replay, cleanup까지 완료하는 것이다. 현재 이미지는 그 성공을 나타내지 않는다.

관리사 · self-scoped 일정 empty projection

frontend 4edc0fa9412d8fb3479189f6e71a403a28e146ae에서 fixture dashboard를 제거하고 실제 관리사 세션의 SSR query를 연결했다. /caregiver/dashboard와 GET /caregiver-work-schedule-projections?scheduleScope=all은 모두 200, 결과는 0건이었다. 가짜 관리사 이름, 평점, 정산 금액은 표시하지 않고 아직 연결되지 않은 기능을 숨겼다.

desktop · 실제 인증 read · 일정 0건

mobile · overflow 없음 · 일정 0건

공개 WebP는 실제 원본에서 관리사 profile identifier와 생성 시각만 픽셀 마스킹했다. sanitized run summary와 supplemental manifest에 원본 run의 범위와 asset SHA-256을 기록한다.

다음 성공 조건은 test-owned 배정 일정 한 건을 만들고 같은 관리사 actor가 일정 확인, 출근·진행 command, 일일 리포트 제출, 지급 projection까지 순서대로 수행한 뒤 정리하는 것이다. 현재 0건 화면은 관리사 A-Z 성공이 아니다.

현재 actor chain 판정

Actor	현재 확인	미확인
산모	인증 refresh, 실제 route 도달, 503 fail-closed	열 카드, 편집, final review, confirm
지점 운영자	self-scoped worklist 200, 산모 403, 501/50 pagination	context materialization이 있는 command mutation·replay
관리사	self-scoped schedule 200, honest 0건, fixture 제거	일정 row, 출근, 서비스, 리포트, 지급
HQ 관리자	이번 run의 actual 성공 증거 없음	지점 생성부터 전체 정산 승인까지 전부

이 표는 13단계 actor chain coverage를 보완한다. 새 성공 run이 생길 때 두 페이지와 manifest를 같은 commit에서 갱신한다.