산모 가족 대리 예약 A-Z 시나리오 증거

이 페이지는 산모 가족 대리 예약 전체 흐름의 재현 절차와 실행 증거를 함께 관리한다. 화면 존재만으로 완료를 주장하지 않는다. 공개 계약, 인증 세션, 워크플로우 결과, 재무 원장 결과가 모두 맞아야 성공이다.

역사 시나리오·증거 페이지

마이그레이션 순서와 PASS/RED/BLOCKED 판정의 현재 권위는 Actor A-Z 워크플로우 Acceptance SSOT와 ADR-033이다. 이 페이지의 기존 단계표·mock 회귀·실패 캡처만으로 phase를 건너뛰거나 PASS를 주장할 수 없다.

2026-07-15 산모·지점 운영자·관리사 실제 실행은 actor별 실제 테스트 증거에서 한눈에 확인한다. 추가된 원본 공개 자산은 지점 운영자 desktop, mobile, summary와 관리사 desktop, mobile, summary다.

프로비저널 증거 — 완료 근거 아님

최신 캡처는 clean frontend source와 stage backend 운영 컨텍스트를 연결한 로컬 브라우저 실행이다. 배포 artifact가 아니며 canonical visual-evidence registry에 등록되지 않았다. ADR-028과 ADR-031은 accepted 상태다. 각각 산모 제출자 분리와 서버 소유 draft→final-review→creation 경계를 승인하지만, 구현 상태는 각각 partial이다. 현재 권한 제약은 accepted ADR-012, ADR-018, ADR-028, ADR-031을 따른다. 이 페이지와 latest manifest는 구현 완료, 배포 완료, 전체 마이그레이션, 100% parity를 증명하지 않는다. latest manifest의 relatedProposals는 승인 전 캡처 시점의 역사 메타데이터다. 현재 결정 상태는 ADR 인덱스가 권위이며, 이후 생성기는 ADR-028과 ADR-031을 accepted lineage로 기록한다.

2026-07-15 실제 인증 세션 · current-source API 착수

실제 실패 증거 — A-Z 완료 아님

stage 산모 Supabase 세션을 실제 refresh하고, 배포하지 않은 현재 backend source를 격리 sidecar로 실행한 뒤 로컬 Astro dev proxy를 통해 브라우저를 연결했다. API route를 mock하지 않았다. desktop/mobile 모두 POST /customer-reservation-drafts까지 도달했지만 HTTP 503과 customer reservation persistence authority is unavailable을 받았다. 따라서 첫 입력 카드도 열리지 않았으며 아래 이미지를 예약 성공 증거로 해석하면 안 된다.

desktop 1440×1100 · draft create 503 · active card 0

mobile 390×844 · 같은 persistence 차단

재현 경계와 판정:

1. frontend a57617eff12818d32a29c021ce7a6788b1b1c804를 로컬 Astro 4321에서 열고, SANMOPIA_DEV_API_PROXY_TARGET으로 현재 소스 backend sidecar만 연결한다.
2. 저장된 산모 refresh token을 Supabase Auth에 제출한다. refresh 응답 200을 확인하되 문서 artifact에는 email, bearer, refresh token을 기록하지 않는다.
3. /mother/booking을 desktop/mobile Chromium에서 연다. 브라우저는 실제로 POST /customer-reservation-drafts를 한 번씩 보내고 각각 503을 받는다.
4. stage DB 최고 migration은 20260713031000이고 draft persistence 시작 migration 20260713170000은 미적용 상태다. 온라인 stage를 변경하지 않고 별도 disposable Supabase에 전체 migration을 적용해 성공 경로를 이어서 검사한다.
5. 공개 run summary와 supplemental manifest의 상태·SHA-256을 대조한다.

이 증거가 확인하는 것은 인증, 브라우저→Astro proxy→현재 FastAPI route 연결, fail-closed UI뿐이다. 열 개 카드 순차 공개, 자동 scroll/focus, 이전 답변 편집, downstream invalidation, final review, confirm은 disposable Supabase 성공 run이 생기기 전까지 계속 미검증이다.

실행 영상

데스크톱 전체 흐름

모바일 전체 흐름

모션 축소 설정에서는 정지 WebP를 표시한다. 실행 manifest는 여기에서 확인한다.

서버 draft 단일 채팅 회귀 · frontend fb69309

실제 Chromium UI 증거 · backend runtime 증거 아님

아래 실행은 frontend fb69309642e5a400a0b80e7e69df2e304a741493의 /mother/booking을 로컬 Astro 7에서 실제 Chromium으로 조작했다. 다섯 draft API와 workflow progress API는 상태를 유지하는 route mock이다. 따라서 한 화면·한 현재 카드, 자동 scroll/focus, 이전 카드 편집, 서버 응답 기반 downstream 무효화, 409 복구, 200 미완료 응답과 typed 422 field error의 현재 카드 유지, 내부 코드가 아닌 사용자 문구, 14-section final review의 연락처·출산/아기·돌봄환경 retained display, 각 정보 카드 안의 수정 버튼, 확정 후 progress UI는 증명한다. PostgreSQL, Supabase adapter, HTTP composition, 배포, 구버전 parity는 증명하지 않는다. 따라서 P04는 계속 RED/partial이다.

데스크톱 · 10개 입력 단계 → final review → 확정

모바일 · 같은 12프레임

편집·충돌·검증 분기

A-Z 재현 절차

1. UI와 evidence harness revision fb69309642e5a400a0b80e7e69df2e304a741493, contract 0f5f33324b3a4ee4bad1d40b9faa8d102c0bd5b1, backend 5be421944e279d1e5d916dfb6fe7732c7da732db를 고정한다.
2. frontend에서 pnpm playwright:customer-reservation-draft-chat-evidence를 실행한다. harness는 로컬 Astro를 127.0.0.1:4327에서 사용하고 실제 Chromium을 desktop 1440×1100, mobile 390×844로 연다.
3. mock이 26개 revisioned option catalog와 인증된 draft create 응답을 내는지 확인한다. 화면이나 JSON에는 bearer와 idempotency key의 실제 값을 남기지 않는다.
4. applicant_authority부터 contract_and_payment_preference까지 열 개 입력 단계를 순서대로 저장한다. 저장 전에는 이후 카드가 없어야 하며, 저장 직후 다음 카드 하나만 열리고 focus와 viewport 교차가 새 현재 카드로 이동해야 한다.
5. final_review query projection에 신청자, retained 연락처·출산/아기·돌봄환경, 주소·coverage, 일정, 관리사 추천, 확정 금액, 계약 버전을 표시한다. 세 retained 정보 카드마다 해당 chat step으로 돌아가는 수정 버튼이 있고 browser가 가격·지원·기간을 다시 계산하지 않는지 확인한다.
6. confirm command 뒤 workflow progress를 읽어 접수번호, 예약번호, completed, 결제 준비 금액을 표시한다.
7. 완료 draft에서 mother_contact를 다시 연다. PATCH 응답의 downstreamInvalidationSet을 적용해 이후 여덟 step input을 제거하고 service_addresses 한 장만 현재 카드로 여는지 확인한다.
8. stale revision을 주입해 PATCH 409를 만든다. 자동 재PATCH는 금지하며 사용자가 다시 확인을 누른 뒤 GET 한 번으로 최신 draft를 읽는지 확인한다.
9. 연락처 PATCH가 HTTP 200과 validation result를 반환하게 한다. 현재 카드를 유지하고 내부 field/message/result code를 숨긴 사용자 문구를 표시하며 다음 카드를 열지 않는지 확인한다.
10. 연락처 PATCH가 typed 422 field error를 반환하게 한다. draft revision을 바꾸거나 다음 카드를 열지 않고 현재 카드의 해당 입력을 다시 선택하도록 안내하는지 확인한다.
11. desktop/mobile 각 12프레임, 편집·충돌·두 검증 summary, network/console 결과와 모든 파일 SHA-256을 실행 manifest에서 대조한다.

각 단계의 원본 desktop/mobile PNG 24개도 같은 evidence 디렉터리에 보관한다. desktop 실행 요약, mobile 실행 요약, 편집 요약, 충돌 요약, 200 검증 요약, 422 검증 요약, 원본 실행 manifest를 함께 감사한다.

검증 gate: runner 성공, frontend 91 files / 575 tests, full lint, Astro check, Astro build 통과. 예상된 PATCH 409와 422 resource console은 각 summary에 별도 분류했고 예상 밖 console/HTTP 오류와 failed request는 0이다.

이전 immutable UI 회귀 31c4a67 역사 증거

retained-intake 공개 section 추가 전 기준을 삭제하지 않고 desktop sequence, desktop poster, mobile sequence, mobile poster, edit, conflict, validation, typed validation, desktop summary, mobile summary, edit summary, conflict summary, validation summary, typed validation summary, run manifest를 보존한다.

이전 immutable UI 회귀 b460d84 역사 증거

최신 회귀로 덮어쓰지 않고 desktop sequence, desktop poster, mobile sequence, mobile poster, edit, conflict, validation, desktop summary, mobile summary, edit summary, conflict summary, validation summary, run manifest를 보존한다.

누적 backend·UI·actor-chain 역사 증거 펼치기

서버 HTTP 조립 증거 · backend 6cc9d2e

코드·in-process HTTP 증거 — 브라우저·PostgreSQL 증거 아님

contract 8ce891f30026741efc2e20e3453979e078ae190c의 생성 Python 모델을 backend 6cc9d2efbb5d64b40628fe78ccabd1721f997513가 직접 사용한다. FastAPI main에 다섯 draft route, 인증된 산모 actor, 단일 Supabase persistence adapter가 조립됐다. 그러나 production option catalog와 final-review authority resolver는 명시적 unavailable adapter다. 따라서 권위 자료가 없는 create, update, final-review, confirm은 성공을 꾸미지 않고 fail closed한다. 이 절에는 새 브라우저 이미지를 붙이지 않는다. 실제 UI/runtime run이 아니기 때문이다.

검증 범위:

1. 생성 contract request/response와 structured 409를 transport 경계에서 그대로 쓴다.
2. bearer session은 backend에서 검증하고 active mother profile 하나만 actor로 인정한다.
3. draft GET/PATCH, final review, confirm이 같은 durable repository instance를 공유한다.
4. stale revision과 semantic final-review conflict를 오류 문자열 파싱 없이 typed kind로 매핑한다.
5. HTTP tests 18, actor/runtime tests 8, feature/main/architecture 포함 140 tests가 통과했다.
6. Ruff, Tach exact/external, Tach MCP 전체 검사, Vulture confidence 100 검사가 통과했다.

전체 backend suite는 이 증거와 분리한다. 기존 reservation smoke import collection 오류 한 건과 reservation-creation 외 기존 실패 일곱 건이 남아 있으므로 전체 suite green 또는 stage 성공으로 기록하지 않는다. clean PostgreSQL replay, 실제 권위 resolver, 인증 브라우저 stage run이 추가되기 전 ADR-031은 계속 partial이다.

바우처 이용일 카탈로그 권위 · backend 2c744fb

백엔드·실 PostgreSQL 증거 — 새 화면 증거 아님

이 증분은 service_schedule.voucher_service_days의 가격 권위와 producer 경계를 검증한다. UI를 변경하거나 브라우저를 실행하지 않았으므로 새 스크린샷·WebP를 만들지 않았다. 위의 b460d84 화면 증거를 이 백엔드 런의 통합 증거로 재사용하지 않는다.

1. legacy SERVICE_DAY_LIST의 slash 토큰 위치를 이용일 순서로 고정한다. SQL encounter order와 workbook row_number로 정렬하지 않는다.
2. exact revision selector로 immutable normalized voucher-plan revision 하나만 읽고, latest 또는 mutable import batch 재조회로 추론하지 않는다.
3. published·zero-issue·complete price batch, contiguous source position, positional classification, option/price-line/entry-code 일대일 대응을 publication RPC가 검사한다.
4. 한 선택지는 의도적으로 standard, 두 선택지는 shortened/standard, 세 선택지는 shortened/standard/extended로 정규화한다.
5. named orchestration이 금액을 노출하지 않는 days_N 옵션만 reservation catalog contribution inbox로 보낸다. Pricing application과 Reservation application 사이의 직접 feature import는 없다.
6. focused 35 passed, Ruff 통과, Tach 진단 0, Vulture confidence 100 후보 0을 확인했다. isolated PostgreSQL 17에서 first publish, idempotent replay, payload conflict, 명시적 15→5→10 순서, service-role direct DML 거부, invalid position 거부, migration reapply를 확인하고 임시 DB를 삭제했다.
7. affected tests는 1,736 passed이며 실패 3건은 parent 83ac5b8에서도 같은 access-control 검사로 재현됐다.

2c744fb 증분 시점 production runtime에는 trusted revision population과 draft-trigger invocation이 없었고 exact-26 materializer도 없었다. 따라서 해당 증분은 새 브라우저 캡처 대상이 아니며 ADR-031은 계속 partial이었다.

바우처 카탈로그 population 권위 · backend c1937ed

백엔드·실 PostgreSQL 증거 — 새 화면 증거 아님

이 증분은 completed source, atomic population, exact selection을 검증한다. UI를 변경하거나 브라우저를 실행하지 않았으므로 새 스크린샷·animated WebP가 없다. 위 b460d84 화면 증거와 2c744fb publication 증거를 새 통합 런처럼 재사용하지 않는다.

1. source completion이 published batch header와 전체 child-entry-set fingerprint, source evidence, ordered service-day slices를 한 번에 고정한다.
2. service detail→tier, baby type→child group, delivery count→delivery order, explicit benefit band, day→service-day count를 명시적으로 결합한다. consume_type prefix로 가격 축을 추론하지 않는다.
3. atomic population RPC가 exact source order, 모든 voucher entry의 일대일 coverage, required/optional/additional component role·basis·amount, effective window를 검사한다. 두 번째 revision이 실패하면 첫 revision도 남지 않는다.
4. published revision read는 population_key가 연결된 revision만 허용한다. exact selector는 네 canonical axis와 quote date로 committed population 하나를 요구하며, caller가 revision, batch, version, latest를 지정하거나 추론할 수 없다.
5. service role은 source completion, bulk population, exact resolve만 실행할 수 있다. anon/authenticated와 폐기된 단건 publisher, 내부 helper 실행은 거부된다. 세 authority table은 service-role select-only다.
6. focused 66 passed, Ruff 통과, Tach 진단 0, Vulture confidence 100 후보 0, isolated PostgreSQL smoke 통과, supabase db lint 결과 0을 확인했다. smoke는 malformed source, header/entry/evidence drift, reversed order, second-revision rollback, idempotent replay, exact selector, ACL을 검사하고 최종 rollback했다.
7. affected tests는 1,758 passed이고 실패 3건은 기존 global access validator와 reservation-collaboration SQL extraction baseline이다. stage·온라인 배포는 없었다.

c1937ed 증분 시점에는 approved workbook/source completion caller와 trusted draft-trigger invocation, exact-26 materializer가 미완료였다. 따라서 ADR-031은 partial이며 이 절은 UI 편의성 또는 A-Z 예약 성공 근거가 아니다.

서버 소유 voucher exact-selection bridge · backend b44fd49

백엔드 orchestration 증거 — 새 화면 증거 아님

이 증분은 reservation catalog bridge의 authority input만 좁힌다. UI·HTTP route·draft trigger를 변경하지 않았으므로 새 스크린샷·animated WebP가 없고 A-Z 예약 성공을 주장하지 않는다.

1. bridge command에서 caller-supplied catalog revision, import batch, price version, consume-type revision을 제거했다.
2. command는 canonical service-detail, baby, delivery, consume-type axes와 quote date만 받고 Pricing Settlement decision port가 committed population의 exact selection을 만든다.
3. bridge는 decision criteria drift를 revision read 전에 거부하고, production runtime은 Supabase exact selector와 population-linked revision source를 함께 조립한다.
4. focused 13 passed, Tach affected 17 passed, Tach 진단 0, Vulture confidence 100 후보 0, Ruff 통과를 확인했다.
5. PATCH 뒤 바로 이 handler만 호출하면 새 revision의 exact-26 snapshot이 없어 다음 카드를 열 수 없다. approved source caller, canonical-axis resolver, 남은 24 producer, same-set exact-26 materializer와 snapshot refresh 전까지 trigger는 미연결로 둔다.

stage·온라인 배포·브라우저 실행은 없었다. ADR-031은 계속 partial이다.

승인된 voucher source completion 권위 · backend 7a9d26e

백엔드·실 PostgreSQL 증거 — 새 화면 증거 아님

HQ 승인→source completion→population 권한·원자성만 검증했다. UI·브라우저 실행이 없어 신규 스크린샷·animated WebP도 없다. b460d84를 이 런의 통합 증거로 재사용하지 않는다.

1. bearer는 active Supabase session actor여야 하고 SpiceDB hq_settlement:price_catalog_management의 manage 권한을 통과해야 한다.
2. caller actor/time/manifest 주입은 거부한다. PostgreSQL이 최초 approved_at과 replay 결과를 소유하고, frozen header+ordered slices+batch/workbook+normalized entry fingerprint에서 canonical manifest SHA-256을 계산한다.
3. exact workbook object/SHA, catalog/version, normalized entry equality를 검사한다. legacy unapproved completion/publication service-role 실행은 철회되고 approved RPC만 허용된다. 기존 unapproved population은 보존하되 resolve/publication에서 격리한다.
4. immutability, insert guard, deferred population/revision linkage 검사가 승인 뒤 drift를 막는다.
5. migration lexical 포함 focused 106 passed(warning 1), fresh isolated PostgreSQL migration+smoke, populated old-schema upgrade+quarantine smoke가 통과했다. relation-aware PL/pgSQL 13개 검사는 diagnostic 0이었다.
6. Tach all/exact/external 0, Vulture confidence 100 후보 0, affected 1,880 passed, 3,359 deselected다. 실패 3건은 같은 기존 unrelated baseline이다.

실제 workbook/source/version은 선택·승인·호출하지 않았고 154 / 0도 자동 선택하지 않았다. stage·온라인 배포·브라우저 실행은 없다. 7a9d26e 증분 시점에는 canonical resolver, draft prepare, 24 producers, exact-26 materializer, final review, payable handoff와 actor A-Z가 남아 ADR-031은 계속 partial이었다.

exact-26 current-set materializer · backend 20a79e3

백엔드 handler/runtime/CAS 증거 — UI 성공·영상 증거 아님

이 증분은 backend 20a79e30e36c6693002c65f8211275afbe149310의 exact-26 materialization 경계만 검증한다. UI를 변경하거나 브라우저를 실행하지 않았고 stage·온라인 배포도 하지 않았다. 신규 스크린샷·animated WebP가 없으며, 위 b460d84 또는 다른 화면을 이 백엔드 런의 통합 증거로 재사용하지 않는다.

1. MaterializeCustomerReservationStepOptionCatalogSnapshotHandler는 한 owner/draft/revision 범위의 current contribution set을 읽고 정확히 26개의 고유 binding과 sequence를 요구한다.
2. application policy는 current window, source-revision 일관성, canonical 26-key snapshot, selection-reference option의 exact authority coverage를 검사한 뒤 authoritative fingerprint와 ordered contribution-set fingerprint를 계산한다.
3. SupabaseCustomerReservationStepCatalogContributionSetSource는 full-row payload와 반환 scope를 엄격하게 읽고, SupabaseCustomerReservationStepCatalogSnapshotMaterializer는 전체 expected lineage/payload/window/fingerprint를 CAS RPC로 보낸다. 반환 receipt의 scope, fingerprints, ordered lineage가 하나라도 다르면 fail closed한다.
4. production runtime은 source와 sink를 같은 Supabase database port에 조립하지만, trusted draft prepare/PATCH trigger에는 연결하지 않는다.
5. migration 20260715090000_customer_reservation_step_catalog_exact_set_materializer.sql은 최신 contribution sequence를 canonical binding 순서로 고정하고, 같은 scope lock 안에서 current exact 26과 caller expected set을 다시 비교한다. 최초 write는 26개 lineage row와 selection authority를 함께 고정하고 exact replay만 허용한다.
6. loader는 current 26의 lineage와 contribution-set fingerprint가 frozen snapshot과 같을 때만 읽는다. 신규 contribution이 올라오거나 25개 이하만 남으면 이전 snapshot을 반환하지 않는다.
7. focused application/adapter/runtime run은 193 passed, 좁은 integrated materializer run은 38 passed, migration/SSOT contracts는 14 passed였다. Ruff, Tach all/exact/external, Vulture confidence-100, PL/pgSQL error check와 git diff --check도 통과했다.
8. scripts/supabase_local_customer_reservation_step_catalog_exact_set_materializer_smoke.sql 을 isolated supabase/postgres:17.6.1.136 관련 predecessor DB에서 실행했다. exact-25 atomic fail, exact-26 snapshot+26 lineage+5 authority, replay 불변, stale CAS 40001, lineageless 거부, invalid/expired newest no-fallback, Asia/Seoul→UTC/Los Angeles fingerprint, Python lineage/Unicode canonical hash, 4개 state table RLS와 service-role RPC-only ACL이 모두 PASS했다. 끝의 ROLLBACK 후 publisher는 기존 2개, fixture user/contribution/snapshot/lineage는 모두 0이었다. 이는 full-history reset, stage, production source 증거는 아니다.

handler, runtime composition, same-set CAS, frozen lineage, stale-lineage read gate는 구현됐다. 하지만 실제 source/version 선택·승인·population, canonical draft-axis resolver, trusted trigger, 나머지 24 producer, complete current set, final review, payable handoff와 actor A-Z 성공은 없다. 따라서 UI에서는 성공 catalog를 본 적이 없고 ADR-031은 계속 partial이다.

catalog preparation authority staging · backend 863158c

DB 권위 기반 증거 — source-owned 준비·UI 성공 증거 아님

이 증분은 backend 863158c743e2bc48e3db1dbb1a1f9d65edb0892d의 catalog-preparation projection, dormant orchestration, offering override precedence만 검증한다. HTTP/PATCH/queue/trigger/worker를 활성화하지 않았고 stage나 온라인 배포, 브라우저 실행도 하지 않았다. 신규 스크린샷·animated WebP가 없으며 기존 화면을 이 DB 실행의 통합 증거로 재사용하지 않는다.

1. CustomerReservationCatalogPreparationAuthority는 한 owner/draft/source-revision에 필요한 17개 catalog, branch/region, birth, pricing, offering-policy, voucher 축과 생성/만료 시간을 전달한다.
2. Supabase record/load RPC는 canonical payload SHA-256, projection id, monotonic projection revision, 최대 15분 window와 exact replay를 소유한다. table은 RLS이며 service role도 SELECT만 가능하고 write는 RPC로 제한된다.
3. loader는 absolute newest row를 먼저 선택한 뒤 draft state/revision, service_offering object, window, payload fingerprint와 projection id를 다시 검증한다. newest가 corrupt/expired면 과거 row로 fallback하지 않는다.
4. service-offering reader는 적용 가능한 중복 row를 offering/policy key당 하나로 줄인다. precedence는 combined branch+region, branch, region, global이며 같은 scope에서는 최신 effective_from, 결과에서는 stable key order를 사용한다.
5. named preparation handler는 authority lineage를 기존 service_offering.offerings와 service_schedule.voucher_service_days 두 contribution에 보존하고 exact-26 handler를 호출하도록 조립됐다. 외부 caller가 없어 side effect는 없고, 24 producer가 비어 있으므로 활성화해서는 안 된다.
6. focused run은 65 passed; Tach affected는 1,932 passed, 기존 unrelated baseline 3 failed, 3,405 deselected였다. Ruff, Tach all/exact/external, Vulture confidence-100과 diff check는 zero다.
7. 현재 migration SHA 273c753dd2fa5f4c08a14bc2a2f65c7ed44832f25d256729c5123aa0fd4ba900을 disposable PostgreSQL database에 두 번 적용했다. replay revision 1 -> 1, expiry renewal 2, 새 projection id와 같은 payload fingerprint, newest load, malformed string/null draft step, corrupt/expired newest no-fallback를 포함한 negative 6건, table/RPC ACL을 모두 검증했다.
8. 같은 DB에서 PGMQ extension/schema, queue relation/function, trigger는 모두 0이었다. 종료 후 disposable database를 강제 삭제했고 잔존 이름 count도 0이었다.

이 증거는 source-owned 17-axis resolver/recording caller를 만들지 않는다. 24 producer, 15분 projection refresh, atomic record-plus-outbox/enqueue readiness, final-review materializer, payable handoff와 actor A-Z가 남는다. 따라서 ADR-031과 체크리스트 상태는 계속 partial이다.

catalog preparation source lineage v2 · backend 59d29eb

백엔드 계약·DB 증거 — runtime E2E·화면 증거 아님

backend cleanup 406d56565eae8ff51a7ec354a1c68aadb11db90c와 59d29eb79359018f116c0be941c6d1a288e44e5c는 source-lineage-bound v2 준비 권위를 검증한다. concrete source adapter, record-handler runtime 결선, HTTP/PATCH/queue/worker activation, stage·온라인 배포, 브라우저 실행은 없다. 신규 스크린샷·animated WebP를 만들지 않았고 기존 화면을 이 증거로 재사용하지 않는다.

1. draft derivation은 birth_occurred, 출산예정일까지의 calendar day, actual_baby_count, continuation_requested만 소유한다. branch, 현재 사전예약, 서버-linked continuation, policy, source price version, voucher criteria를 추측하지 않는다.
2. consumer-owned port는 branch_coverage, reservation_state, service_offering_policy, price_catalog_version, voucher_plan_criteria 다섯 결정을 요구한다. 각 lineage는 owner/reference/revision/SHA-256과 정확한 valid_from/valid_until을 갖는다.
3. typed record는 current pre-reservation과 historical conversion, actual baby count와 voucher baby classification, source price-version id와 calendar version number, extension request와 server-linked continuation을 구분한다. voucher birth rank/workforce도 step2 birth method와 다른 용어다.
4. migration 20260715110000_customer_reservation_catalog_prepare_authority_v2.sql의 SHA-256은 a980b468843ebd07d58b3952d122748d82e77dcfca9277eae210344452aa7d92다. 17축 payload와 다섯 lineage를 함께 fingerprint하고 v1 record/load RPC의 service-role 실행 권한을 철회한다.
5. record RPC는 PostgreSQL statement_timestamp()로 Asia/Seoul 영업일을 계산하며 evaluated_on == quoted_on을 강제한다. 테스트는 2026-07-14T14:59:59Z를 서울 2026-07-14, 2026-07-14T15:00:00Z를 서울 2026-07-15로 구분한다. 만료는 draft, 15분, 가장 이른 source expiry, 다음 서울 자정 중 최솟값이다.
6. load RPC는 caller as_of를 받지 않고 DB statement time을 사용한다. newest row의 scope, draft freshness, exact lineage, source window, combined fingerprint, projection id가 어긋나면 older v1/v2 row로 fallback하지 않는다.
7. 40일 사전예약은 오늘을 1일째로 포함한다. voucher 입주 제한은 actual baby count가 아니라 canonical voucher baby classification을 사용하며, 그 분류가 없으면 fail closed한다.
8. service_offering.offerings publication은 정확한 preparation-authority catalog lineage 없이는 거부된다. 공개 availability endpoint 결과는 preview이며 booking 권위가 아니다. 현재 booking은 caller decision을 받아들이므로 activation 전에 server projection을 다시 읽어 검증해야 한다.
9. focused verification은 109 passed; full suite는 5,427 passed와 기존 historical security-validator failure 1건이다. Ruff src, Tach exact, Vulture confidence-100은 통과했다. 앞선 real disposable PostgreSQL 17 v1→v2 smoke도 통과했다.

현재 concrete source adapters는 0/5, record-handler runtime wiring은 0, runtime E2E axes는 0/17, activation surfaces는 0이다. 24 producer, refresh, final-review materializer, payable handoff와 actor A-Z도 남으므로 ADR-031과 체크리스트는 계속 partial이다.

단일 채팅 타임라인 회귀 · frontend 579e159

UI 동작 증거 — A-Z 성공 증거 아님

아래 정지 WebP와 상단 animated WebP는 단일 타임라인, 한 번에 하나인 현재 카드, 자동 스크롤·focus, 이전 답 수정 시 downstream 무효화를 검증한다. stage 산모 세션으로 운영 컨텍스트를 읽었지만 예약 POST는 실행하지 않았다. 예약·결제·서비스·정산 성공 주장에 사용하지 않는다.

데스크톱 · 제출 준비

데스크톱 · 결제 위임 답변 수정

모바일 · 제출 준비

모바일 · 결제 위임 답변 수정

재현 절차

1. frontend revision 579e1596283f977f993617e831abacdb9df62f14를 사용한다.
2. Astro 7 source dev 서버를 stage backend internal URL과 연결한다. stage 산모 세션은 브라우저 쿠키로만 주입한다.
3. /mother/booking을 desktop 1440×1100, mobile 390×844로 각각 연다.
4. 카드 1부터 11까지 한 장씩 답한다. 각 답 직후 다음 카드만 열리고 focus와 중앙 스크롤이 다음 입력으로 이동하는지 확인한다.
5. 마지막 카드에서 완료 11/11, 제출 버튼 enabled, backend canonical serviceType=postpartum-standard-10d, paymentMethod=card를 확인한다.
6. RESERVATION_FLOW_EDIT_PROBE_STEP=payment_delegation으로 결제 위임 수정을 누른다. 완료 카드 7, 현재 카드 1, 현재 step payment_delegation, focus true, 이후 카드 DOM 0, 일정 초기화를 확인한다.
7. desktop/mobile 모두 HTTP 4xx/5xx, failed request, console error가 0인지 확인한다.
8. asset 해시와 한계는 UI manifest와 실행 manifest로 검증한다.

검증 gate: frontend 전체 54 files / 311 tests, lint, TypeScript, Astro check, Astro build 통과. Playwright desktop/mobile 실행은 예약 mutation을 수행하지 않았다.

이전 UI 구조의 프로비저널 회귀 자료는 desktop ready, desktop edit, mobile ready, mobile edit, manifest에 보관한다.

구버전 대비 바인딩 감사 · 2026-07-13

UI 구조 수정 완료 · 데이터 parity 미완료

단일 채팅 타임라인은 요구한 표현 구조로 교체됐지만, 현재 11개 카드가 모두 예약 명령의 계약 필드로 이어지는 것은 아니다. 실제 제출에 직접 도달하는 핵심 값은 motherId, schedule, serviceType, paymentMethod 네 개다. 이 절은 100% 마이그레이션을 주장하지 않기 위한 blocker 기록이다.

구버전 단계	현재 상태	판정
산모 연락처·비상연락처·자택/서비스/제2주소	산모 ID와 단일 방문 주소 UI만 존재한다. 주소는 최종 제출 필수 gate가 아니다.	contract/backend blocker
출산·아기·조리원·큰아이·반려동물	구조화된 예약 snapshot 필드가 없다.	미바인딩
서비스 유형·근무형태·기간·시작일·추가일·대여·추가옵션	일정과 서비스 타입만 제출된다. 기간·휴일 카드 선택은 payload에 도달하지 않는다.	부분 바인딩
스마트 매칭 순위·성향·환경 조건	관리사 힌트는 UI draft다. 현재 첫 backend 후보 자동 선택을 제거하고 server decision ID/revision을 받아야 한다.	권위 경계 blocker
전체 검토·계약 동의·서명·결제	최종 review projection, contract version, acceptance, signature가 없다. 결제는 예약 후 obligation 기준 command로 분리해야 한다.	미구현

권한 관련 P0는 더 엄격하다. reservation_sponsor의 로컬 boolean은 accepted ADR-021의 grant·revision·산모 acceptance를 대신할 수 없다. 결제 위임은 accepted ADR-020의 예약 후 obligation을 따라야 하며, 열람 범위는 accepted ADR-024의 booking-scoped 권한 결과를 조회해야 한다. 가격·지원·쿠폰·정산은 accepted ADR-012에 따라 frontend 계산이 아니라 frozen backend projection이어야 한다.

따라서 다음 구현은 Layer-first로 domain ← application ← adapters/interfaces ← orchestration 의존을 지키며 final-review projection과 축소 command 계약부터 연결한다. feature 간 직접 import는 port/contract 없이 허용하지 않고, CQRS 폴더는 실제 command/query가 생기는 slice에만 둔다.

실제 stage 인증 예약 · 2026-07-13

부분 성공 증거 — 예약 workflow 범위만

아래 증거는 실제 stage Supabase 산모 세션으로 대화 카드 11개를 순차 완료하고, 예약 workflow가 202 → completed → scheduled에 도달한 실행이다. 외부 결제 승인, 서비스 제공, 관리사 지급, 지점·본사 정산은 이 실행에서 수행하지 않았다. 따라서 전체 A-Z나 마이그레이션 완료 근거로 사용할 수 없다.

11단계 순차 진행 animated WebP

데스크톱 제출 직전

데스크톱 예약 확정

모바일 제출 준비

재현 및 감사 절차

1. backend 4e87532ecb94dd282bab965f283f35050110d079, frontend db2338945fc68897e72ac346d503da50c823624c를 사용한다.
2. Astro 7 dev 서버를 SANMOPIA_BACKEND_INTERNAL_URL과 PUBLIC_SANMOPIA_API_BASE_URL이 stage API를 가리키는 상태로 시작한다.
3. stage Supabase 산모 refresh token으로 access token을 갱신한다. 브라우저에는 sb-access-token, sanmopia-supabase-access-token 쿠키만 주입한다.
4. /mother/booking을 desktop 1440×1100, mobile 390×844로 연다.
5. 카드 1부터 11까지 한 장씩 답한다. 매 답변 뒤 다음 카드만 열리고 자동 스크롤과 focus가 다음 입력 또는 최종 CTA로 이동하는지 확인한다.
6. desktop에서 실제 제출한다. POST /reservation-booking-workflow-starts의 202, request projection의 completed, 예약 상태 scheduled, UUID booking id를 확인한다.
7. mother-visible charge와 disclosure readiness를 조회한다. HTTP 4xx/5xx, failed request, console error가 모두 0인지 확인한다.
8. workflow 원장에서 requested_by_user_id == mother_user_id, submissionActor.actorKind == mother, submission actor와 branch actor 분리를 확인한다.
9. 생성한 booking UUID를 기존 stage reaper batch에 등록한다. cleanup 뒤 booking과 financial lifecycle이 0, batch가 reaped, SpiceDB cleanup이 검증됐는지 확인한다.
10. 값과 cleanup 결과는 실행 요약, asset 해시와 한계는 manifest로 확인한다.

실행 후 SSR 운영 컨텍스트와 제출 API가 동일한 server base URL을 사용하도록 frontend b2448dc78307aed1ae7efeec71702e56725131ae에서 보강했다. 네트워크/상대 URL 예외도 사용자 안전 오류로 변환한다. 전체 gate는 49 files / 282 tests, lint, Astro check, Astro build 통과다. 단, 위 mutation 증거의 실행 revision은 db23389다.

실제 지사 정산 projection · 2026-07-13

읽기 성공 증거 — 지사 A-Z 완료 아님

stage 지사 운영자 세션으로 실제 backend 정산 projection을 읽었다. desktop/mobile 모두 ready, “백엔드 projection 조회 완료”, 브라우저 오류 0이었다. 그러나 수동 정산 행 246개가 contract gap으로 표시된다. 입금 확인, 지급 승인, 정산 검토, export, 본사 승인은 실행하지 않았으므로 지사 parity나 actor A-Z 완료를 주장하지 않는다.

데스크톱 projection

모바일 projection

재현 및 감사 절차

1. frontend b2448dc78307aed1ae7efeec71702e56725131ae, backend 4e87532ecb94dd282bab965f283f35050110d079를 사용한다.
2. 만료된 stage 지사 운영자 access token을 refresh token으로 갱신한다. refresh HTTP 200과 두 인증 쿠키 주입을 확인한다.
3. /pricing-settlement?branchProfileId=00000000-0000-0000-0000-000000000101을 desktop 1440×1100, mobile 390×844로 연다.
4. settlementBoardState=ready, backend projection 완료 문구, frontend 계산 경고 부재를 확인한다.
5. HTTP 4xx/5xx, failed request, console error가 모두 0인지 확인한다.
6. GET만 수행했으므로 business cleanup은 없다. 실행 요약과 manifest에서 범위, gap 수, asset 해시를 확인한다.

HQ 결제 변경 운영 보드 · frontend 6ef99f9

인증 조회 성공 — 완료 mutation 근거 아님

HQ 관리자 actor의 실제 stage GET은 200, 지점 actor의 같은 GET은 403이었다. desktop/mobile 모두 보드가 ready였고 검색·초기화 동안 기존 지점 query context가 보존됐다. 그러나 stage 보드는 0건이었다. test-owned 완료 가능 행이 없어 완료 POST와 동일 idempotency key replay는 실행하지 않았다. 이 절은 결제 변경 하위 workflow의 조회 근거이며 지점 예약 처리나 HQ 전체 정산 완료 근거가 아니다.

데스크톱 · 조회 → 검색 → 초기화

모바일 · 조회 → 검색 → 초기화

재현 및 감사 절차

1. frontend 6ef99f95e981f83f4a76fd39aaf78a71980965b7, backend 52def804e2ee1179c288c3052dc29f5b35c65d79를 사용한다.
2. 로컬 Astro SSR의 SANMOPIA_BACKEND_INTERNAL_URL을 stage API로 설정한다.
3. 고정 stage HQ 관리자와 지점 운영자 토큰을 메모리에만 발급한다. 파일·manifest·화면에는 토큰, 이메일, 세션 경로를 기록하지 않는다.
4. API를 직접 읽어 HQ 200, 지점 403, HQ visibleRowCount=0, returnedRowCount=0을 확인한다.
5. HQ 쿠키로 /pricing-settlement?branchProfileId=…을 desktop 1440×1000, mobile 390×844에서 연다. ready, 조회 결과 0건을 확인한다.
6. stage-empty-board-evidence를 검색한다. URL과 hidden field에 기존 branchProfileId가 남고 보드가 계속 ready인지 확인한다.
7. 초기화를 누른다. 검색어만 제거되고 지점 context와 ready가 유지되는지 확인한다.
8. 행이 생기는 미래 실행을 위해 캡처 전 식별자·금액 cell을 마스킹한다. run summary에는 allowlist된 auth 진단과 aggregate count만 기록한다.
9. 현재 완료 가능 행은 0이므로 business mutation을 실행하지 않는다. 행이 준비되면 별도 rollback-owned 실행에서 completed, 동일 key replay, cleanup을 증명한다.
10. 실행 요약과 manifest에서 권한 매트릭스, 한계, WebP 해시를 확인한다.

frontend는 인증 쿠키를 SSR bearer로 변환하고 ready, needs_token, forbidden, failed를 분리한다. backend가 이미 검색·권한 처리한 row를 다시 로컬 필터하지 않으며 visibleRowCount와 returnedRowCount를 구분한다. 완료 controller는 bearer와 결정적 Idempotency-Key를 쓰고 성공 직후 SSR을 재조회한다. 이 command 경로는 frontend 51 files / 292 tests, lint, Astro check, Astro build로 검증했지만 live mutation은 위 이유로 미증명이다.

지점 예약 운영 worklist · contract 18955f7 · backend c9b06d7 · frontend 1f95287

실제 지점 조회 성공 — 예약 mutation 근거 아님

지점 운영자 principal에서 서버가 지점 membership을 결정한 GET은 200, 산모 actor의 같은 GET은 403이었다. 실제 stage projection은 501건, 첫 page는 50건이며 일정 확정 17건, 완료 33건이었다. desktop/mobile에서 조회, 상태 필터, 결과 없음, 초기화가 동작했고 console error와 failed request는 0이었다. 그러나 operation context decision이 있는 행은 0건이었다. 화면은 이를 숨기지 않고 가능 작업 없음으로 표시하며 mutation을 잠갔다. 이 절은 지점 예약 목록 read parity의 부분 실제 근거이지 지점 예약 처리 A-Z 완료 근거가 아니다.

데스크톱 · 전체 조회 → 일정 확정 → 결과 없음 → 초기화

모바일 · 전체 조회 → 일정 확정 → 결과 없음 → 초기화

재현 및 감사 절차

1. contract 18955f7e2f49adafffa1e56ddea1f46840f9f929, backend c9b06d7263ad2e25dfb969d1bc111536419e8264, frontend 1f9528766fd3ae1b7b6b3ec4828a1a2a05aa6825를 사용한다.
2. stage backend 컨테이너를 바꾸지 않는다. committed local backend를 별도 컨테이너로 실행하고 stage Supabase와 SpiceDB network에 연결하되 이 시나리오는 GET만 수행한다.
3. stage 지점 운영자와 산모 session을 refresh한다. 토큰, 이메일, refresh token, session path는 manifest, 브라우저 event, 화면에 기록하지 않는다.
4. GET /branch-reservation-operation-worklist?limit=50을 지점 운영자로 호출해 200, 산모로 호출해 403을 확인한다.
5. 요청 URL·query·body에 branchProfileId나 actor를 보내지 않는다. backend가 authenticated user의 branch_operator membership 1건과 SpiceDB branch:view를 확인한 후 DB query 자체에 branch filter를 적용하는지 테스트로 확인한다.
6. 직접 API summary에서 visibleItemCount=501, returnedItemCount=50, cursor 존재, scheduled=17, completed=33, decision row 0을 확인한다. 이름과 식별자는 summary에 넣지 않는다.
7. 로컬 Astro SSR의 SANMOPIA_BACKEND_INTERNAL_URL을 위 local backend로 설정한다. 지점 운영자 cookie로 /pricing-settlement#reservation-operation-command-board를 연다.
8. desktop 1440×1000, mobile 430×932에서 ready, 50건, 실제 존재하는 상태 lane 두 개만 표시되고 빈 상태 lane은 렌더되지 않는지 확인한다.
9. 상태를 일정 확정으로 바꾸고 17건과 한 개 lane을 확인한다.
10. evidence-no-match를 검색해 명시적 0건 empty state를 확인한 뒤 초기화로 50건을 복원한다.
11. 캡처 직전 예약·지점·산모·관리사·일정·갱신시각을 DOM에서 마스킹하고 Astro 개발 toolbar를 숨긴다. 캡처 중 console error와 failed request가 모두 0인지 확인한다.
12. 실행 요약과 manifest에서 revision, 권한 매트릭스, 관찰값, asset SHA-256, 한계를 확인한다.

public row는 canonical business reservationId, revision, 표시명, 일정, 상태, decision만 노출한다. booking/context UUID와 raw user id는 노출하지 않는다. decision은 표시 근거이며 actor나 실행 권한 descriptor가 아니다. 기존 command boundary가 principal 기반 branch와 actor, expected revision, Idempotency-Key를 서버에서 강제하기 전에는 executionReady=false가 유지된다. 현대 상태는 15개로 정렬했지만 legacy 연장요청, 사전예약대기, 입금대기취소, 사전예약취소의 독립 의미는 아직 보존하지 못하므로 상태 parity 100%를 주장하지 않는다.

13단계 actor chain coverage · 2026-07-13 감사

단계별 판정이 완료 주장보다 우선

contract 18955f7, frontend 1f95287, backend c9b06d7와 local assembly evidence를 기준으로 legacy source, 현대 계약·구현, 실제 actor UI, runtime/visual 증거를 다시 대조했다. 부분은 그 단계의 하위 계약이나 backend 실행이 있다는 뜻일 뿐 actor A-Z 완료가 아니다. 첫 단절점은 1 · 지점 추가다.

#	Actor 결과	현재 판정	다음 증거 조건
1	본사 관리자가 지점을 추가	없음	HQ 인증 create, duplicate login conflict, replay, identity·SpiceDB 관계, 신규 지점장 로그인
2	지점장이 자기 지점정보를 조회·수정	부분	인증 actor에서 own branch를 서버가 결정하는 GET과 update stage proof
3	산모 회원가입	없음	signup route, Auth/profile 원자성, 중복·검증 오류, 신규 세션
4	산모 예약	부분 실제	desktop stage 예약 성공은 있음. clean four-repo pins와 mobile mutation proof 필요
5	지점 예약 처리	부분 실제	principal-scoped 실제 board read·필터 WebP는 있음. branch mutation·conflict·replay proof 없음
6	관리사 매칭	부분	예약 입력 후보 전달뿐. 지점 확정 UI와 assignment stage proof 필요
7	결제	부분 실제	사전등록과 HQ 보드 인증 GET·검색 WebP는 실제. provider-originated 승인, 완료 row mutation·replay 필요
8	서비스 진행	부분 backend	backend driver만 존재. 관리사 actor UI와 서비스 진행 mutation proof 필요
9	관리사 앱 확인	부분 실제	인증 관리사 일정 GET 200과 honest empty UI는 있음. test-owned 일정, 출근 command, success·conflict 화면 필요
10	관리사 작성·산모 열람 일일 리포트	부분/Demo	caregiver persistence와 mother review를 같은 booking으로 증명해야 함
11	관리사 정산	부분/Demo	payout 원장 일부만 존재. 실제 관리사 portal 조회·확인 proof 필요
12	지점 정산	부분 실제	projection GET은 실제. 246 contract-gap 행과 mutation·export 미완료
13	본사 정산	부분 실제	HQ 결제 변경 하위 보드 GET은 실제. 이것만으로 HQ 전체 승인·완료를 주장할 수 없음

프론트 surface 감사상 실제 backend 연결 화면은 산모 예약, 산모 결제 사전등록 일부, 지점 예약 worklist, 지점 정산 projection, HQ 결제 변경 보드 읽기, 관리사 self-scoped 일정 empty projection이다. 지점정보·일일 리포트·관리사 정산 화면은 fixture/Demo이거나 미연결이고, 지점 추가·산모 회원가입·서비스 진행·HQ 전체 정산은 actor surface가 없다. 따라서 fixture 스크린샷은 canonical 성공 증거로 승격하지 않는다.

backend 438e8dc는 기존 branch-office API/HTTP/tests를 interfaces/branch_operations/features/office_profile로 이동하고 public package·구조 가드·Tach module을 추가했다. f0f32bb는 Tach 영향 테스트가 발견한 정산 export fixture의 dataset revision lineage를 복구했다. 이 두 커밋은 Layer-first 경계와 테스트 신뢰성을 개선하지만 지점 onboarding 기능 완료 증거는 아니다. Tach exact/interfaces/dependencies/ external 진단 0, Vulture confidence 100 후보 0, 영향 테스트 528 passed다. backend 52def80는 같은 지점 운영 context의 service-area policy 인터페이스를 interfaces/branch_operations/features/service_area_policy로 이동했다. 계약·route 동작은 바꾸지 않았고 추가 영향 테스트 514 passed, Tach 진단 0, Vulture 후보 0을 확인했다.

A-Z 절차

1. A · 인증: Supabase 산모 세션을 준비하고 탈퇴·만료 세션을 거부한다.
2. B · 운영 정보: /mother-booking-operational-context에서 산모, 지점, 서비스, 결제수단, 관리사 후보를 읽는다.
3. C · 가족 계정: 예약을 돕는 가족 역할을 선택한다. 선택값은 권한 증거가 아닌 draft다.
4. D · 산모 확인: 백엔드가 제공한 산모 식별자를 확인한다.
5. E · 방문 권역: 주소와 접근 참고사항을 입력하고 주소 증거 payload로 변환한다.
6. F · 서비스 기간: 희망 기간을 입력한다. 실제 서비스일과 추가일은 백엔드가 확정한다.
7. G · 휴일 및 중단: 선호만 제출한다. 휴일 정책과 중단 가능성은 서비스 달력 결정이 소유한다.
8. H · 관리사 힌트: 매칭 선호를 제출한다. 배정과 점수는 백엔드 결정이다.
9. I · 예약 진행자: 가족 대리 또는 산모 직접 예약 의도를 고른다. 실제 권한은 인증·가족 grant로 재검증한다.
10. J · 결제 위임: 가족 결제 의도를 고른다. payer, 범위, 한도, revision은 백엔드 snapshot이 소유한다.
11. K · 가격·지원·쿠폰: 확인 희망만 입력한다. 금액은 accepted price quote와 benefit decision에서 온다.
12. L · 이력 공개: 산모가 볼 범위를 선택한다. 문서·결제·돌봄 열람은 각 backend capability가 재검증한다.
13. M · 일정·서비스: 운영 context가 허용한 서비스 key와 일정 범위만 제출한다.
14. N · 제출 검증: 공개 계약이 필수 intent field와 금지된 브라우저 권위 필드를 검사한다.
15. O · 예약 시작: POST /reservation-booking-workflow-starts가 202를 반환한다.
16. P · 워크플로우 조회: 예약 request projection이 최종 booking id와 완료 상태를 반환한다.
17. Q · 가격 확정: mother-visible charge projection이 고객 부담액을 반환한다.
18. R · 결제 진행: 결제 workflow가 completed로 끝난다.
19. S · 서비스 제공: backend driver가 서비스 제공 사실과 occurrence ledger를 기록한다.
20. T · 관리사 지급: frozen charge와 배정 근거로 관리사 지급 지시를 만든다.
21. U · 지점 정산: 고객 부담액에서 관리사 지급액을 제외한 지점 정산을 기록한다.
22. V · 본사 정산: 남은 금액을 본사 정산 원장에 기록한다.
23. W · 정산 완료: 재무 lifecycle이 settled에 도달한다.
24. X · 브라우저 검증: HTTP 실패, failed request, console error가 모두 0인지 확인한다.
25. Y · 증거 고정: desktop/mobile frame hash와 네 저장소 revision을 manifest에 기록한다.
26. Z · 신선도: manifest 유효기한이 지나거나 asset hash가 바뀌면 docs check를 실패시킨다.

프로비저널 통합 runner 출력

• 예약 workflow: 확정
• 결제 workflow: completed
• 산모 부담액: 1,680,000원
• 최종 재무 단계: settled
• 지점 정산: 100,000원
• 관리사 지급: 1,580,000원
• 본사 정산: 0원
• 원장 줄 수: 3
• 브라우저 HTTP/console 실패: 0

값은 프로비저널 manifest에 고정된 backend driver 중심 stage 실행 관찰이다. 각 actor가 브라우저에서 13단계를 수행했다는 뜻이 아니다. clean four-repo pin과 배포 artifact digest를 가진 canonical 증거도 아니며, 최신 실행이 달라지면 이 절과 manifest를 같은 변경에서 갱신한다.

P04 대여용품 catalog publication supplement

Backend 4c9dd40fcef076d1e27fb5f053af82ad92f2cbb1와 frontend 3dd5779b4c1133d812786dbc0419c0d29234bd1e는 대여용품을 코드 상수나 직접 SQL로 관리하지 않는 실제 actor publication gate를 고정한다. Pricing Settlement의 immutable revision, application command/port, Supabase publication adapter와 production composition, DB-owned SHA-256/count 및 append-only supersession을 사용한다.

Pinned Supabase CLI로 migration 315/315를 적용한 disposable PostgreSQL/PostgREST, real GoTrue HQ·비권한 actor, real SpiceDB 권한, production FastAPI/Astro server와 Chromium을 route interception 없이 연결했다. HQ actor는 현재 5개를 조회하고 UI에서 여섯 번째 용품과 source evidence를 입력해 immutable revision을 발행했다. Exact replay, altered replay 503과 DB 무변경, 비권한 GET/POST 403, revision 2, supersession 1, published entry 6, evidence 1, actor/relationship/runtime cleanup을 통과했다.

상세 A→Z와 desktop/mobile WebP는 overflow 0, rail 88px, console/failed request 0과 cleanup을 기록한다. Actual manifest는 asset hash, runtime, privacy와 completionClaim: false를 소유한다. 본사 대여용품 관리 하위 게이트는 GREEN이다. 실제 산모 선택→Supabase draft→quote·charge handoff→final review는 아래 최신 rental pack에서 닫혔다. 이 pack 단독으로는 confirmation-ready booking·payment, production source 승인과 final confirm이 남아 있었다. 아래 current integrated pack이 synthetic test-owned authority의 기술 final confirm은 닫았지만 법적 acceptance와 service-balance·settlement·문서의 후속 소비는 여전히 남아 P04는 RED/partial이다. 온라인 배포는 하지 않았다.

P04 실제 local supplemental evidence

최신 통합 기술 pack은 actual signature confirmation manifest이다. Backend c6eb6f2c467c4ca1d3fd1855d2abc11b74e4416b, contract 132e1a4e1077770247a17397efffceeb0699c045, frontend ffacc93939528f0e21d098d8fdf41bef3f978f07의 실제 owner desktop/mobile Chromium이 GoTrue → Astro production server → FastAPI → PostgREST → private Storage → READY → atomic confirm → exact replay를 한 disposable full replay에서 통과했다. Migration 321/321, actual 422/409/403/401, evidence/consumption/command 1/1/1, 예상 밖 console/page/failed request 0, cleanup PASS다.

Desktop · 실제 transport · READY→CONSUMED · confirm 201

Mobile 390px · pointer 입력 · exact replay · overflow 0

이 pack의 시각 asset 53개는 수동 privacy review를 통과했지만, 법률 bundle·approval·문구· 서명/보존 정책은 test-owned synthetic이다. Assembly도 ADR-032 작성 중 변경 때문에 clean pin이 아니었다. 따라서 allRequiredTechnicalProofs=true와 별개로 status=provisional, completionClaim=false, P04 RED와 공식 3/13 (23.1%)를 유지한다.

계약 동의 source와 provisional UI는 별도 보조 pack으로 보존한다. Legacy contract source manifest는 구버전 agree.png와 3rd.png의 byte-identical SHA-256, 공유 selector와 현대 법무 seed가 아니라는 경계를 기록한다. Contract acceptance UI manifest는 backend 69b708f7, contract d6f0d0ff, frontend 248f4f9d에서 실제 Chromium desktop/mobile 순차 카드, 자동 scroll/focus, exact synthetic wording, 필수·선택 item과 required-signature fail-closed를 기록한다. API와 법률 값은 test-owned synthetic이므로 actual backend confirm, durable signature, 법무 승인, production publication 또는 P04 PASS 증거가 아니다.

최신 signature capture UI manifest는 backend 731f321d, contract ba6df817, frontend e833eb15, assembly pre-doc c80be389를 고정한다. 실제 Chromium desktop 1440×1100과 mobile 390×844에서 pointer/touch/keyboard canvas, raw PNG mock upload 각 3회, 등록 뒤 pixel 제거, item/review binding 변경 시 폐기와 redraw, mock confirm을 통과했다. 공개 파일 59, manifest asset 58, 예상 밖 console warning/error와 failed request 0이다.

Desktop · 동의 → draw → 등록 → 폐기 → redraw → mock confirm

Mobile 390px · touch canvas · 같은 A→Z 절차

등록 직후 · Blob/canvas pixel 제거 · reference 비노출

Backend 731f321d는 이 mock UI와 별개로 Supabase CLI migration 320/320과 실제 pinned Storage API에서 canonical PNG digest roundtrip, immutable collision, anonymous existence hiding, DELETE/missing, production adapter, PENDING orphan cleanup, READY consume-vs-cleaner race와 disposable cleanup을 통과했다. 두 기술 하위 게이트는 GREEN이지만 같은 실제 actor run이 아니다. 실제 authenticated owner browser→FastAPI→private Storage→READY→atomic confirm, 실제 법무 approval payload와 배포는 미증명이므로 P04는 계속 RED/partial이고 공식 진도는 3/13 (23.1%)다.

최신 authenticated mother rental pack은 actual rental browser manifest이다. Backend 288e14a7·frontend 93b8c2e1의 실제 desktop/mobile 단일 채팅에서 health_cushion_rental 선택, voucher occurrence 10, 장비료 0원, 왕복 배송비 10,000원, payable 210,000원, rental catalog/selection SHA-256 handoff, final review 200, 자동 focus/scroll, 편집/reprojection과 actual 422/409/403/401을 통과했다. 공개 파일은 45개, manifest asset은 44개이며 confirm은 비활성이다.

P04의 현재 부분 검증은 actual browser manifest이 소유하던 이전 current-pin 회귀다. Astro production build/preview same-origin 경로에서 desktop/mobile 열 카드, 완료 섹션 편집, actual 422 current-card 유지, actual stale 409 explicit refresh, branch/caregiver actual create 403, foreign-mother resume GET 403, test-owned missing-header resume GET actual 401과 여섯 animated WebP를 backend 35f67ff9 current pin에 묶는다. Confirm은 비활성이어서 party snapshot confirmation 경로는 실행하지 않았다. 이전 resume-authorization browser manifest, create-authorization browser manifest, validation/conflict browser manifest, browser manifest와 5-actor backend manifest은 역사 supplemental pack이다. 이 P04 산모 예약 pack들은 프로비저널이다. 위 본사 대여용품 pack은 실제 actor/backend/database 하위 게이트지만 P04 PASS나 배포를 뜻하지 않는다. 역사 대여용품 UI-only manifest도 레이아웃 회귀 자료로 보존하며 actual pack을 덮지 않는다. 본사 계약 발행 UI manifest는 Astro production build의 승인 패킷 선택·명시적 확인·발행 영수증 desktop/mobile 화면을 고정한다. API는 합성 route이므로 실제 HQ actor·backend·DB 증거가 아니며 P04 RED를 바꾸지 않는다.

이 UI의 actual 후속 pack은 본사 계약 실제 발행 manifest다. HQ actor → Astro → FastAPI → GoTrue/PostgREST/PostgreSQL → SpiceDB 경로에서 최초 발행, exact replay, altered replay 차단, 비권한 403, 직접 DB 검증과 cleanup을 통과했다. 짧은 절차와 WebP를 우선 읽는다. 같은 verification-owned handoff의 산모 final confirm manifest도 desktop/mobile 201, exact replay, private signature consumption을 통과했다. 짧은 통합 절차를 본다. production 법무 권위가 아니므로 P04는 계속 RED다. 이전 selector 검증은 역사 본사 발행 manifest로 보존하며 현재 pack의 판정을 덮지 않는다.

완료되지 않은 범위

• 모바일 실행은 카드 전 단계와 제출 준비 UX를 증명한다. 현재 manifest의 실제 제출·정산 완료는 데스크톱 실행이 증명한다.
• 외부 결제 공급자 callback, 부분 환불, 서비스 중단, 가족 grant 교체·철회, 관리자 브라우저 정산은 별도 시나리오로 증명해야 한다.
• HQ 결제 변경 하위 보드의 인증 GET·검색 캡처는 공개 provisional evidence에 있다. 관리사 일정 dashboard는 실제 인증 GET 200을 표시하지만 결과가 0건이고 평점·정산은 미연결이다. HQ 전체 정산 dashboard와 실제 actor mutation이 생기기 전에는 canonical evidence로 승격하지 않는다.
• 이 페이지는 해당 별도 시나리오를 대신하지 않는다.
• canonical docs/evidence/visual-evidence.json registry에는 실제 actor 전이만 승격한다. 최신 signature canvas pack은 stateful mock API 증거이므로 이 registry에 등록하지 않았고, public supplemental evidence와 MDX 절차에서만 기술 경계를 증명한다.