Actor A-Z 워크플로우 Acceptance SSOT

이 페이지가 산모피아 마이그레이션 actor workflow의 사람용 기준이다. 기계 기준은 workflow/sanmopia_actor_chain.v1.yaml, 결정 권위는 ADR-033이다. 설명, 테스트, 실행 증거가 서로 다르면 YAML과 validator가 문서 gate를 실패시킨다.

현재 판정: 3/13 PASS · P04 RED

• P01–P03: 실제 actor, 권한, validation/conflict/replay, cleanup, desktop/mobile/WebP PASS.
• P04 기술 경계: 실제 GoTrue·FastAPI·PostgREST·Supabase·Astro에서 단일 채팅 10단계, private signature READY → CONSUMED, atomic confirm 201, exact replay, 422/409/403/401, cleanup PASS.
• P04 차단: 실행 packet이 synthetic_test_only다. 운영 법무 승인 wording·item code· signature rule·retention과 동일 revision 산모 final confirm이 없다.
• P05: backend·frontend 기술 준비. P06: backend·contract·관리사 모바일 accept/reject UI 준비. 둘 다 순차 gate와 실제 actor evidence 전에는 BLOCKED다.
• 공식 진도: 3/13 (23.1%), completionClaim: false.

P01 persistence의 세부 순서와 실제 DB 판정 기준은 P01 Supabase 내구성 검증 기준이 소유한다. 최종 actor·browser 절차와 증거는 P01 실제 Acceptance A-Z에서 확인한다. 아래 P01 RED/GREEN 기록은 각 당시의 역사이며 현재 판정을 덮지 않는다. P02의 구현 전 기준은 P02 RED 역사 기록, 최종 actor/browser 증거는 P02 실제 Acceptance A-Z가 소유한다. P03의 최종 actor/browser/retention 근거는 P03 완료 검증 A-Z가 소유하며, 이전 P03 부분 검증은 역사 기록이다. P04의 현재 backend runtime 근거와 남은 gate는 P04 실제 backend 부분 Acceptance가 소유한다.

순차 검증 규칙

legacy source 고정 → workflow/test RED → contract → backend → frontend
→ isolated actual actor → API/primary state/replay/권한 → desktop/mobile/WebP
→ Starlight/ADR → PASS → 다음 phase RED

• 이전 phase는 전부 pass, 현재 phase는 정확히 하나만 red, 이후는 전부 blocked다.
• 각 phase는 happy_path, authorization, validation, conflict, exact_replay, cleanup 여섯 분기를 contract/backend/frontend에서 모두 추적한다.
• PASS에는 실제 actor mutation, Supabase primary-state, SpiceDB 관계 권한, exact replay, conflicting replay 무변경, cleanup이 필요하다. Restate가 선택된 workflow는 durable progress도 필요하다.
• 생산 phase는 실제 actor 전이, 영속 replay-safe handoff, immutable downstream lineage를 증명한다. blocked consumer의 실제 command 실행은 생산 phase PASS 조건이 아니며, 해당 consumer phase가 current가 된 뒤 자체 actor/state 증거로 닫는다.
• desktop, mobile, 실제 상태 전이가 담긴 animated WebP, privacy review, 4개 repo immutable revision이 모두 필요하다. 반복 프레임 영상, mock route, read-only 200, 빈 projection은 PASS가 아니다.
• 구현 경로는 Layer-first다. application/<context>/features/<feature>를 사용한다. CQRS는 각 feature 안에서 필요한 commands/queries만 둔다.

13개 phase

순서	Phase	Actor	Before → After	현재 상태
01	P01-branch-onboarding	HQ 관리자	branch 없음 → branch r1 + operator identity/membership + parent_hq/hq_admin/branch_operator	PASS · 실제 actor/API/primary state/replay/race/cleanup/browser/WebP 증거 등록 완료
02	P02-branch-manager-profile	지점 운영자	최소 onboarding profile → 자기 지점 complete profile revision	PASS · actor 13/6/2, 실제 API/primary state/replay/cleanup/browser/WebP canonical 증거 등록 완료
03	P03-mother-account-profile	산모	미가입 → verified auth/profile/consent	PASS · 신규 6-case + 역사 계정 8-case + 인증 HQ Chromium + retention/purge + cleanup 완료
04	P04-mother-reservation-chat	산모	draft 없음 → 열 카드 + final review + booking handoff	RED · partial · actual browser 기술 replay는 backend c6eb6f2c + contract 132e1a4e + frontend ffacc939. 승인 publication 경계는 backend 810b03b + contract 8ae043d에서 RFC 8785 handoff, 전용 SpiceDB 권한, immutable Supabase transaction, exact replay까지 GREEN. 운영 법무 패킷 게시·clean four-repository actual run·deployment가 없어 PASS 아님.
05	P05-branch-reservation-handling	지점 운영자	submitted intake → 상담/처리 revision + audit/outbox	blocked · backend d33be2b1 + frontend a1c331c readiness GREEN. 반응형 Chromium 증거만 있고 actual actor/state/replay/cleanup 없음
06	P06-caregiver-matching-assignment	지점→관리사	matching ready → assignment decision + 수락 + obligations	blocked · backend 443c989c + contract d232992 + frontend browser UI readiness. actual actor/state/replay/cleanup 없음
07	P07-mother-payment	산모	payment ready → verified receipt + reservation continuation	blocked
08	P08-service-start-delivery	지점 운영자	confirmed/not started → in service + frozen day obligations	blocked
09	P09-caregiver-schedule-attendance	관리사	attendance due → accepted attendance + 산모 notification outbox	blocked
10	P10-daily-reports	관리사→산모	report due → caregiver submission + mother acknowledgement	blocked
11	P11-caregiver-payout	지점→관리사	payout review ready → deposit + receipt acknowledgement	blocked
12	P12-branch-settlement	지점 운영자	statement issued → line review + HQ→지점 수령 확인 + 지점→HQ 납부	blocked
13	P13-hq-settlement	HQ 관리자	branch acknowledged → HQ-approved immutable closeout ledger	blocked

Phase별 필수 acceptance case

아래 ID가 테스트 이름·실행 manifest·증거 문서에서 그대로 유지돼야 한다.

Phase	Case IDs
P01-branch-onboarding	P01-happy-path, P01-authorization, P01-validation, P01-conflict, P01-exact-replay, P01-cleanup
P02-branch-manager-profile	P02-happy-path, P02-authorization, P02-validation, P02-conflict, P02-exact-replay, P02-cleanup
P03-mother-account-profile	P03-happy-path, P03-authorization, P03-validation, P03-conflict, P03-exact-replay, P03-cleanup
P04-mother-reservation-chat	P04-happy-path, P04-authorization, P04-validation, P04-conflict, P04-exact-replay, P04-cleanup
P05-branch-reservation-handling	P05-happy-path, P05-authorization, P05-validation, P05-conflict, P05-exact-replay, P05-cleanup
P06-caregiver-matching-assignment	P06-happy-path, P06-authorization, P06-validation, P06-conflict, P06-exact-replay, P06-cleanup
P07-mother-payment	P07-happy-path, P07-authorization, P07-validation, P07-conflict, P07-exact-replay, P07-cleanup
P08-service-start-delivery	P08-happy-path, P08-authorization, P08-validation, P08-conflict, P08-exact-replay, P08-cleanup
P09-caregiver-schedule-attendance	P09-happy-path, P09-authorization, P09-validation, P09-conflict, P09-exact-replay, P09-cleanup
P10-daily-reports	P10-happy-path, P10-authorization, P10-validation, P10-conflict, P10-exact-replay, P10-cleanup
P11-caregiver-payout	P11-happy-path, P11-authorization, P11-validation, P11-conflict, P11-exact-replay, P11-cleanup
P12-branch-settlement	P12-happy-path, P12-authorization, P12-validation, P12-conflict, P12-exact-replay, P12-cleanup
P13-hq-settlement	P13-happy-path, P13-authorization, P13-validation, P13-conflict, P13-exact-replay, P13-cleanup

레거시 기준에서 고정한 핵심 차이

영역	레거시 실제 동작	새 acceptance 기준
지점 생성	profile·credential·계좌·회비가 한 form에 섞이고 controller role guard가 약함	HQ capability, 복구 가능한 branch/identity/membership/relationship outcome, exact replay. branch_operator relation이 manage permission을 부여하며 manage라는 relation은 없음
지점 자기 프로필	GET만 session branch로 치환하고 POST는 caller $index를 신뢰한다. JavaScript 1-10은 readonly 표시뿐이며 저장은 credential·lifecycle·계좌·회비까지 섞는다.	초대 activation → authorization pending delivery → SpiceDB 검증 → branch id 없는 자기 GET/PATCH. 첫 PATCH는 표시·연락·구조화 주소만, CAS/replay/typed 409 diff/closed 422를 소유
산모 가입	이메일 중복확인은 있으나 이메일 소유·휴대폰 본인인증과 약관 version 증거 없음	verified identity와 versioned consent 없이는 complete 불가
예약 작성	PROCESS_NO 0→4와 status 혼합, 첫 단계 편집은 기존 draft 삭제	동일 draftId/revision, 서버 dependency graph, 원자적 downstream stale
채팅 UX	여러 PHP page로 분리	한 채팅뷰, 현재 카드 하나, 저장 뒤 다음 카드 공개·자동 scroll, 완료 섹션 편집
지점 처리	client가 상태 숫자를 제출하고 side effect가 후속 비원자 처리	server-owned allowed command, revision, idempotency, durable side effects
출근·리포트	notification과 오늘 날짜/read flag가 source of truth 역할	assignment/service-day obligation과 versioned submission
정산	userToDanbee는 HQ/단비→지점 지급, centralToBranch는 지점→HQ 납부지만 이름과 돈 방향이 혼동되고 POST ftype이 권한을 고름	frozen line ledger, 세션 actor별 command, 양방향 line 의미, reversal revision, immutable closeout

P05 backend readiness 상세와 실제 Supabase 동시성 근거는 Reservation Control Collaboration Gap Mining이 소유한다. Backend d33be2b1에서 함수별 SECURITY DEFINER 경계와 누락된 table inventory를 검사하고 focused 92, changed-impact 6310을 통과해 global policy gate도 GREEN이다. 이는 strict sequence를 우회하지 않는다. P04 PASS 전 P05 actor/browser acceptance는 실행하지 않으며 P05 상태는 blocked다.

기존 화면·영상의 위치와 판정

기존 실제 실행은 2026-07-15 actor별 실제 테스트 증거에 있다. 산모 draft 503, 지점 command context 실패, 관리사 일정 200/0건을 정직하게 남겼다. 이것들은 blocker 증거다. 아래 이미지는 현재 runtime truth를 보존할 뿐 새 phase 성공 증거가 아니다.

산모 actual · 실패 · P04 PASS 아님

지점 actual · 실패 · P05 PASS 아님

관리사 actual · empty · P09 PASS 아님

mock 채팅 UI의 desktop/mobile animated WebP는 산모 가족 대리 예약 A-Z 시나리오 증거에 역사 회귀 자료로 남긴다. P04가 current RED가 된 뒤 실제 API·Supabase 상태와 같은 run에서 다시 수집하기 전에는 actor acceptance evidence로 사용하지 않는다. 그 재수집의 partial 경계는 P04 실제 backend/browser 부분 Acceptance에 등록했다. 최신 p04-live-browser-35f67ff pack은 stateful mock이나 CSP 우회 없이 Astro production build/preview same-origin 경로와 actual local GoTrue/FastAPI/PostgREST/Supabase, actual 422/409 recovery, branch/caregiver create 403 UI, foreign-mother resume GET 403, test-owned missing-header resume GET actual 401 UI를 통과하지만 production source completeness와 confirm 성공은 증명하지 않으므로 P04 PASS 근거는 아니다. Confirm-disabled run이라 새 party snapshot confirmation 경로도 증명하지 않는다.

P01·P02 누적 RED/GREEN 실행 ledger 펼치기

P02 canonical PASS

P02 actor는 canonical branch_operator다. branch_manager는 phase ID와 일부 legacy feature의 호환 alias로만 남긴다. profile 권한은 다음 순서를 건너뛸 수 없다.

invited authority → activation → authorizationRelationshipStatus=pending
→ relationship delivery → SpiceDB verify → own-profile GET → self-scoped PATCH

기존 caller-supplied branchOfficeProfileId mutation 우회는 닫혔다. P02 canonical run은 실제 Supabase session과 primary state, runtime worker receipt, SpiceDB permission, self-scoped GET/PATCH를 검증했다. authorization 13, validation 6, conflict 2 variants와 exact replay, cleanup을 통과했고 desktop 2장, 390px mobile 3장, 실제 여섯-frame animated WebP를 같은 pin 집합에 등록했다. 상세 절차와 immutable pin은 P02 실제 Acceptance A-Z가 소유하며 P02 RED Acceptance는 구현 전 문턱의 역사 기록이다.

P01 계약 검증 기록

• 최초 RED: P01-* 여섯 계약 테스트가 모두 실패. /admin/branches와 onboarding schema 부재가 원인.
• 현재 GREEN: contract artifact revision 1f56d28b31a0a5f16045e41bb4555e7eb20e3745.
• application preflight에서 installable Python P01 binding 부재를 발견해 contract gate를 재개했다. strict Pydantic binding, 공개 package export, RFC8785-JCS fingerprint golden vector, wheel import를 추가했고 boolean const: 1 coercion과 중복 conflict path 반례도 독립감사로 폐쇄했다.
• 전체 contract gate: layout, lint, TypeScript build, Jest 48 suites / 431 tests, Python contracts 37 passed 중 P01 14 passed, JSON Schema 2020-12 meta validation, OpenAPI 3.1 validation, Python 3.13 wheel import PASS.
• 독립 반례 감사에서 operatorIdentityId, managerMembershipId, membershipFeePolicyId가 completed side-effect의 referenceId와 달라도 수용되는 cleanup inventory 결함을 발견했다. TS/Python RED 4건을 먼저 고정한 뒤 세 resource/effect parity를 계약 validator에서 폐쇄했다.
• 후속 감사에서 public header와 P01 OpenAPI operation에 Supabase/SpiceDB 및 test cleanup 절차가 섞인 경계를 발견했다. generic bearer contract로 바꾸고 cleanup 실행 절차는 workflow SSOT로 되돌린 뒤 TypeScript, Python, layout, OpenAPI 3.1 전체 gate를 다시 통과했다.
• 여섯 case에 더해 completed/repair-pending 조합, side-effect/aggregate 일치, canonical command fingerprint, exact next actions, cleanup 범위를 실제 Ajv fixture로 검증한다.
• 계약 테스트: contract-repo/packages/ts-client/src/types/branch-onboarding-acceptance_test.ts, contract-repo/packages/python-contracts/src/generated/branch_onboarding_test.py.
• 계약 GREEN은 backend state, 403 무변경, 중복 방지, cleanup 성공 증거가 아니다. P01은 계속 RED다.

P01 도메인 검증 기록

• 도메인 RED는 branch code, 초기 회비 정책, canonical authorization binding, typed field error, 직접 dataclass 생성 우회를 포함해 먼저 고정했다. 추가 반례 커밋은 backend a44f097이다.
• 최종 provider-neutral 도메인 revision은 20aae2afd537c39ea0d9f6a76461909041dd6508이다.
• 대상 테스트 57 passed, domain/branch_operations 회귀 118 passed, Ruff format/check, Python compile, Tach exact boundary/interface/external 0 diagnostics, Vulture confidence 100 0 candidates를 통과했다.
• 독립 반례 검토에서 non-string 오류코드, public contract가 거부하는 공백 branch code/email, provider 명칭 누수를 발견해 RED로 재현한 뒤 수정했다. 재검토 결과는 GREEN이다.
• 이 GREEN은 입력 facts와 revision-one plan의 불변식만 증명한다. HQ authorization, 원자적 Supabase write, Supabase Auth 초대/보상, SpiceDB write, Restate repair, HTTP status, exact replay, cleanup은 application 이후 계층 증거가 없으므로 여전히 RED다.
• 도메인 테스트: backend-repo/src/sanmopia_modernization/domain/branch_operations/features/branch_onboarding/branch_onboarding_test.py.

P01 애플리케이션 검증 기록

P01 application acceptance RED는 backend revision 61a8cf55030414983ba20f3dad953aee98c74f6b에 먼저 고정했다. 새 Python contract의 RFC8785 전이 의존성 lock은 선행 revision 61a10069f8f03c3d2e7be5ddbd1364989f4aa5b9다. 당시 contract snapshot, 생성 command, 현재결과 query production module 부재로 세 collection error가 발생했고, 구현보다 먼저 정직한 실패 기준을 보존했다.

최종 provider-neutral application revision은 8ac9ed9ca937e1521f984aa7de66bd7c3e64855b다. command는 idempotency key와 전체 request만 받고 actor/HQ id는 서버 authority port로 해석한다. 정규화 전 request와 actor의 fingerprint, immutable accepted POST snapshot, repair current projection, typed validation/conflict, exact replay, actor-scoped query를 분리했다. 공백 token을 모두 required로 잘못 분류하던 반례 3건도 RED로 고정한 뒤 invalid_format으로 수정했고, replay 전에 호출 가능한 branch ID port는 I/O나 영속 할당이 없는 순수 로컬 생성 계약으로 제한했다. query command id의 앞뒤 공백과 200자 초과가 reader로 전달되던 후속 반례도 RED로 고정한 뒤 public CommandId 경계와 같게 닫았다.

application focused 57 passed, branch application/domain 회귀 209 passed, Ruff format/check, Python compile, uv lock, Tach exact boundary/interface/external 0 diagnostics, Vulture confidence 100 0 candidates를 통과했다. 이는 port와 use-case 경계만 증명하며 실제 persistence나 actor 성공 증거가 아니다.

P01 어댑터 검증 기록

HQ 권한 adapter의 선행 RED는 SpiceDB schema의 administer_headquarters가 application enum에 없던 불일치를 backend 883ace2ff1a20e28f67395596b81019c0082c988에 고정했고, 76cee7e39f28e5404e7af4e7a3eaeb5bd00b1c4c에서 schema와 같은 이름으로 닫았다. 실제 resolver acceptance는 74fc8623ac2815b3a64d0aff757480d8e76fb1e7에 production module 부재 RED로 먼저 고정했다. 후속 반례 5e0f34f5c3af30d3cdc303813b73a1af969f1f13과 144e1d3c4aab0d2d1d256e895012493bb04c1233은 공백 authenticated subject와 None/비-row Supabase 응답에서 raw 예외가 새던 경계를 typed dependency-unavailable로 고정했다.

독립 감사에서 SpiceDB administer_headquarters가 HQ의 child branch로 상속되므로 membership branch를 그대로 HQ로 승격할 수 있는 반례를 발견했다. RED 1c5d8a0은 child branch를, RED 7b059c5는 root 판정 컬럼 누락과 명시적 SQL NULL을 구분하도록 고정했다. 최종 authority adapter revision은 c4a19418109dd34ce1ba6364c8d1b4040bef9bb7이다. authenticated subject와 같은 server-owned member profile, 단 하나의 HQ membership, 같은 HQ branch scope, 명시적 headquarters_profile_id IS NULL root row, SpiceDB administer_headquarters 허용이 모두 일치할 때만 actor를 반환한다. focused 20 passed, branch adapter/application/domain 및 SpiceDB 회귀 278 passed, Ruff format/check, Python compile, uv lock, Tach exact boundary/interface/external 0 diagnostics, Vulture confidence 100 0 candidates를 통과했다. 이 증거는 P01-authorization의 resolver 조각만 GREEN이다. DB07-13의 완전한 Supabase lifecycle, Auth identity, membership/fee, SpiceDB relationship write, current-result reader, Restate repair와 실제 HQ actor 실행은 아직 RED다.

Current-result adapter acceptance는 production module 부재를 backend 3af680d84380efb03ec11a7c8abadda1ae51ff7c에 RED로 먼저 고정했고, fd35741c20715e7507c88e2b08cb93a1707c82d7에서 암묵적 scalar value 대신 명시적 result_payload RPC column을 고정했다. 독립 감사가 RPC 요청에만 있던 HQ scope를 발견한 뒤 3cddb27b4cdeea2a481bf8ad979dd72a3f0f346e에서 actor, HQ root, command id를 응답 row의 postcondition으로도 묶었다. 최종 reader revision 78781cff20216ebd13a0918be1319e72143b94dc은 정확한 4-key envelope와 strict generated contract만 수용하고, replay delivery variant·scope mismatch·malformed provider response를 typed dependency failure로 닫는다. focused 18 passed, branch 회귀 296 passed, Tach exact 0 diagnostics, Vulture confidence 100 0 candidates, 독립 P1/P2 재감사를 통과했다. atomic start와 일부 transition RPC는 DB01-06에서 실행됐지만 scoped current-result GET RPC와 finalized command/current snapshot은 DB10-12 전까지 없으므로 runtime query 증거는 RED다.

Durable execution 계약은 바로 구현하지 않고 backend 1efe0ab의 첫 RED에서 시작했다. 독립 감사는 all-pending 시작이 Auth 충돌 뒤 부분 branch 행을 남길 수 있고, journal/current를 별도 mutation으로 만들며, accepted fingerprint·audit·완료 effect를 repair에서 되돌릴 수 있음을 확인했다. 후속 RED들은 identity namespace claim과 provisioning 완료를 분리하고, claim id, HQ, idempotency key, 실제 request에서 다시 계산한 fingerprint와 정규화 invitation email, created|attached 보상 소유권을 한 scope에 묶었다. 또한 retrying 실제 resource reference를 보존하고, accepted/current identity ownership을 claim과 대조하며, P02가 소유하는 manager active/invitation accepted 상태를 P01 snapshot에서 거부한다.

최종 durable-port revision 8cf3ffaf9d6e9d184305e198a0c78dbf1713dbce은 focused 55 passed, P01 application 112 passed, branch domain/application/adapter 회귀 323 passed, Ruff, Python compile, uv lock, Tach exact/interface/external 0 diagnostics를 통과했다. Vulture confidence 100의 다섯 후보는 모두 실제 Protocol 포트 파라미터로 확인되어 삭제하지 않았다. 이 기록은 값과 포트 계약만 GREEN이다. DB01-06은 (HQ, idempotency key), claim/identity/email ownership, atomic start, invitation-only transition과 exact replay를 실제 Supabase에서 닫았다. accepted/current freeze, 일반 effect/current CAS, provider effect, Restate의 created-only 보상과 crash resume은 아직 실행 증거가 없어 RED다.

Supabase persistence의 첫 실제 RED는 backend ffffad87429f6021bd0d77cafa56144f8a3e97ef에 고정했다. cached official Supabase PostgreSQL/Storage image, 네 개의 명시적 tracked dependency migration, rollback SQL로 dirty reservation WIP와 unrelated migration lineage를 격리했다. 실제 replay가 끝난 뒤 P01-DB-ACL missing authority table sanmopia_branch_organization_revision_states에서 실패했다. 세부 기준과 격리 근거는 P01 Supabase 내구성 검증 기준이 소유한다.

후속 DB01-02 production은 backend b9e617bed95243073d1b32bb640be6f6f43dd33c에서 GREEN이다. 실제 fresh Supabase replay, db lint error 0, 내부 다섯 authority table ACL, service-role-only security-definer RPC, root-HQ revision 초기화와 CAS, HQ-scoped command/revision identity, revision 7 -> 8, office revision 1, 정확히 다섯 pending effect, 조기 invitation/membership/fee 부재, command-insert late failure의 전체 rollback을 검증했다. 같은 backend state의 P01 colocated 회귀는 207 passed다.

DB03의 production 이전 RED는 backend d93f7f1b183228ac3e0db599e696c5ea39212c24에 고정했다. 실제 fresh Supabase는 P01-DB-INVITATION-ONLY missing side-effect transition RPC에서 실패한다. 테스트는 invitation row 하나와 active membership 0, state revision과 journal의 원자 전이, 다른 네 pending effect, accepted/current null, duplicate invitation reference의 전체 rollback을 요구한다. DB08 일반 CAS와 repair는 이 단계의 성공 조건이 아니다.

DB03 production과 순차 DB04 exact replay는 backend f558b542c39ba8556991cbd8cd19cb4e68d48f1e에서 GREEN이다. transition RPC는 exact command scope와 revision을 잠그고 invitation-only row, journal completed reference, state revision 2를 같은 transaction으로 기록한다. active membership은 0이며 다른 네 effect와 accepted/current는 그대로다. duplicate invitation reference는 선행 journal/state update까지 rollback한다. 독립 감사가 발견한 null expected status와 noncanonical UUID 반례도 무변경으로 닫았다. 최신 snapshot exact replay는 row count를 바꾸지 않는다. DB05 key mismatch부터는 RED이며 P01 전체도 계속 RED다.

DB05 production 이전 RED는 backend 97562ffea2e83308cb1e6a36097cb72ad433c5c8에 고정했다. 동일 HQ/key의 actor, request, fingerprint, command, claim 변조는 모두 exact idempotency mismatch와 열 가지 business row 무변경이어야 한다. 실제 fresh Supabase에서 유효한 다섯 변조는 거부됐지만 claim의 identityId 누락은 nullable UUID의 <> 비교를 우회해 기존 snapshot을 재생했다. production은 아직 변경하지 않았고 이 반례가 첫 DB05 RED다.

강화 DB05 test는 backend e3dc427946eee398bac673c00dcd3db8848278bc, production은 a172a8628159fd24b1e6e25522cbdc49dc666849에서 GREEN이다. 추가 RED로 claim의 HQ/key/fingerprint 누락 replay를 확인한 뒤 raw claim binding, null-safe comparison, canonical UUID를 stored facts에 결속했다. 모든 mismatch는 exact conflict이며 열 가지 row count, 최신 snapshot, HQ revision이 불변이다. fresh key의 missing identity도 첫 write 전 invalid로 거부된다. 실제 fresh Supabase/lint/rollback, 207 passed, 독립 감사 두 건에서 blocker 0을 확인했다. 이 DB05 GREEN 시점에는 DB06 이후가 RED였으며 P01 전체도 계속 RED였다.

DB06 production 이전 RED는 backend 4a66363d12d844d17a8cb51f3c0ca6c14c390beb에 고정했다. 같은 claim의 same/other HQ 재결속은 이미 거부됐지만, 새 claim으로 기존 identity를 다른 email/disposition에 묶은 요청은 실제 fresh Supabase에서 started를 반환했다. identity와 normalized email을 각각 freeze하고, exact ownership conflict, 두 owner snapshot/HQ revision/열 가지 count 불변, candidate 잔여 0, named unique constraint와 서로 다른 HQ의 동시 race까지 통과하기 전에는 DB06을 GREEN으로 선언하지 않는다.

DB06 production은 backend f0c60e9878b82bc21d6203c3f63f2a4a71e393ad, 실제 race harness는 51573cfecfa612877ece205d5c93a5f5128018ba, readiness barrier hardening은 418678accf1cc7aa995c9f22d87e902253aa0e5f, production RPC authority-lock waiter까지의 최종 hardening은 db2a9058edcdd51487f93554fc92bcbda281d04f에서 GREEN이다. identity ID와 normalized email을 각각 named global unique로 고정하고, fresh request는 첫 write 전 claim → identity → email lock과 exact ownership precheck를 통과해야 한다. 직렬 네 재결속은 정확한 claim/namespace 22023으로 거부되고 owner snapshot, HQ revision, 열 가지 count, candidate 부재가 유지된다.

identity와 email race는 각각 서로 다른 HQ/key/claim을 가진 두 backend PID가 readiness를 먼저 commit하고 shared wrapper barrier에서 대기한다. controller는 두 in-call waiter를 확인해 wrapper만 푼 뒤 production RPC의 동일 identity/email authority lock에서 두 waiter를 다시 증명해야 authority를 해제한다. 두 경합 모두 winner 1, exact loser 1, candidate-scoped partial state 0이다. fresh replay, db lint error 0, serial fixture rollback, disposable DB teardown, 207 passed, Ruff, Tach, false-GREEN 보강 뒤 적대적 재감사 blocker/high/medium 0을 확인했다. race winner/audit은 assertion 동안 보존한 뒤 container와 함께 폐기했으며 race rollback으로 기록하지 않는다. DB07 business conflict 이후와 P01 전체는 이 시점에는 계속 RED였다.

DB07은 production 변경 전에 세 독립 fresh command로 기준을 고정했다. stale organization revision, duplicate branch code, duplicate (business_jurisdiction, business registration number)는 각각 정확한 22023 conflict여야 한다. 모든 거부는 기존 두 branch snapshot, 두 HQ revision, 열 가지 authority count를 그대로 유지하고 candidate branch/command를 남기지 않아야 한다. 레거시는 active 관리자 로그인 ID만 중복 검사하고 사업자 식별자 CAS나 원자 rollback이 없으므로, 이 기준은 레거시 동작을 보존하는 동시에 중복 권위와 부분 저장 결함을 명시적으로 개선한다. 기준 revision은 assembly 361de79e536e70d7e7b688ffe2bcfa2c2e44d9b9, 실행 RED는 backend b87e526a7c34828f179c1f48b3182b526d5bbfe5다. actual stale revision case는 exact 22023을 통과했지만 duplicate branch code가 raw 23505와 sanmopia_branch_profiles_branch_code_key를 반환했다. 따라서 typed business conflict production은 아직 없고, 순차 실패 뒤의 duplicate business identity와 DB08 이후도 GREEN으로 주장하지 않는다.

독립 적대감사는 이 직렬 기준만으로 concurrent typed conflict를 증명할 수 없다고 판정했다. production을 열기 전에 서로 다른 HQ의 동일 branch code와 동일 business identity를 각각 실제 두 backend session으로 동시에 실행한다. readiness 2 확인 뒤 barrier를 풀고 winner 1, exact 22023 loser 1, loser candidate partial state 0, 서로 다른 stored/result backend PID를 증명해야 한다. 이 race RED가 없는 직렬 GREEN은 DB07 GREEN이 아니다.

race 기준은 assembly 8476fea9253d18522867e041895afa472ebb577c, 실행 RED는 backend 6eb6d5e17d32a99acdbdb6240b01a60d5c59ed94다. actual two-session branch-code race는 readiness 2와 서로 다른 stored/result backend PID를 증명했지만 loser가 exact 22023 대신 raw 23505와 branch-code constraint를 반환했다. 첫 순차 실패 뒤 business-identity race는 아직 실행 GREEN이 아니다. 따라서 production을 이제 최소 lock/precheck/backstop 변경으로만 연다.

DB07은 최종 경합 증명 backend db2a9058edcdd51487f93554fc92bcbda281d04f, production e540107db0c1cb75244f91b68b836d1b60d5a3c3에서 GREEN이다. 신규 command는 claim → identity → email → branch code → business identity lock 순서를 지키고 stale organization revision을 먼저 판정한다. branch code와 business identity precheck는 각각 exact 22023이며, 기존 두 unique authority에서 발생한 알려진 23505만 같은 typed conflict로 바꾼다. 알 수 없는 unique violation은 그대로 다시 던지고, branch/office insert subtransaction은 office unique loser의 부분 branch를 rollback한다.

직렬 세 conflict는 두 기존 command·live branch/office snapshot, 두 HQ revision, 열 가지 count를 보존하고 candidate branch/command 0을 증명했다. branch-code와 business-identity race는 각각 서로 다른 두 backend session이 run_candidate 내부에서 대기한 뒤 production RPC의 정확한 authority advisory lock에서도 동시에 waiter 2임을 pg_locks로 증명하고 나서만 해제했다. 두 경합 모두 winner 1, exact loser 1, partial 0이다. targeted/full fresh replay, db lint error 0, serial rollback, helper drop, disposable DB 부재, 207 passed, Ruff, Tach를 통과했고 Vulture 세 후보는 Protocol parameter였다. harness와 production 독립 감사 모두 blocker/high/medium/low 0이다. DB08 이후와 P01 전체는 계속 RED다.

DB08 기준은 production 변경 전에 DB03에서 manager membership만 완료한 첫 command의 pre-acceptance durable state에 고정한다. 시작은 state revision 2, completed 1, pending 4, accepted/current null이다. identity, authorization relationship, invitation delivery, fee publication을 각각 exact reference와 failure null로 pending → completed해 revision을 2 → 3 → 4 → 5 → 6으로 전진시킨다. 단계별 반환 snapshot, command revision, 대상 journal row는 한 transaction 결과로 일치하고 최종 effect 다섯 개가 모두 completed여야 한다. branch/office/HQ revision/audit/invitation/ membership/fee 사실은 불변이며 pre-acceptance current는 계속 null이다. stale CAS와 reference rewrite는 DB09, finalize DB10, accepted 이후 repair DB11, GET DB12, cleanup DB13 소유이므로 제외한다.

같은 DB08에서 untouched 두 번째 command는 provider-neutral 성공 전이 matrix를 모두 증명하는 repairable lineage다. identity를 reference 없는 retrying, claim identity reference를 얻은 retrying, 같은 reference의 completed로 전진시키고 authorization effect는 reference와 failure가 있는 retrying에 둔다. revision은 1 → 2 → 3 → 4 → 5, accepted/current는 계속 null이다. 이는 실제 provider 실행이나 DB10 repair-pending finalize, DB11 repair 성공 주장이 아니라 그 두 후속 gate의 정직한 입력이다.

DB08 executable RED는 criteria assembly 034f6da42dadd2d994744bbee3279f6fb4fd68ca 뒤 backend 5e42e8d58d5377481b39a48ec3933289f146a37a에 고정했다. fresh tracked migration replay와 Supabase db lint는 통과했고 첫 operator_identity_provisioning pending → completed 호출이 exact 0A000, branch onboarding transition is outside the enabled DB03 boundary를 반환했다. 실패 subtransaction 전후 private snapshot, 전체 command/journal, 두 HQ revision, 열 가지 authority count, branch/office/ revision/audit/invitation/membership/fee 사실은 모두 동일하다. 테스트는 ordered 8-case progression, stored claim identity reference parity, null-safe 비교를 포함하며 독립 재감사에서 blocker/medium 0이다. disposable DB는 제거됐고 production은 변경하지 않았으므로 DB08과 P01 전체는 계속 RED다.

DB08 production candidate a1f26f7ba27afcb43c0914f74e6d8cf29a5ffbaf은 기존 transition RPC 하나만 확장했고 original ordered eight-case matrix와 full fresh regression을 통과했다. 그러나 독립 감사에서 manager membership pending → retrying이 임의의 non-UUID reference를 저장하는 반례를 찾았다. known reference는 rewrite할 수 없고 completed는 canonical UUID를 요구하므로 이 상태는 복구 불가능하다. backend test b58ee8437cdb297ed8090f1e25c16d1146cc5ec6이 unchanged candidate에서 P01-DB-EFFECT-CAS accepted poisoned manager retry reference를 재현한다. 따라서 candidate evidence는 보존하되 DB08 판정을 RED로 다시 열었다. P01 전체도 계속 RED다.

DB08 final production b63f8eb61e08dddd65bf8f80139c81931eade8ab은 manager membership의 모든 non-null reference를 mutation 전에 canonical UUID로 검증한다. null-reference retry는 유지하고 invitation insert는 completed에만 남긴 one-line fix다. fresh Supabase DB01-08, lint, rollback, identity/email/branch-code/business-identity race의 winner=1 exact-loser=1 partial=0, 207 passed, Ruff, Tach exact/external, Vulture false-positive 검증과 제한 독립 감사 두 건을 통과했다. 따라서 DB08 persistence만 GREEN으로 닫는다. provider/UI/actual actor를 포함한 P01 전체는 계속 RED다.

DB09 criteria는 구현 전에 고정했다. DB08 종료의 completed/repairable 두 lineage를 바꾸지 않고 stale command/effect/reference, reference rewrite, completed regression, malformed JSON type, tab/newline, actor/HQ/key/command/branch cross-scope를 exact typed error와 전체 row 불변으로 거부한다. 레거시 실제 OfficeManagement → Branch_model::putOfficeData는 branch 뒤 token/당월 fee를 분리 저장하고 두 결과를 무시한 채 true를 반환한다. 이 경로에는 manager invitation이 없으므로 초대를 레거시 기능으로 꾸미지 않는다. DB09 executable SQL과 production은 아직 RED다. 독립 사전 감사 뒤 대표값 기준을 폐기했다. malformed JSON은 payload 6 x 4 = 24, canonical payload text는 3 x 3 x 2 = 18, execution scope text는 5 x 3 x 2 = 30 전수 matrix로 고정한다. 각 case 직전 전체 상태를 다시 캡처하고 test-only reference setup까지 exception subtransaction에서 rollback한다. 이 보강도 production 변경 전에 끝낸다. criteria amendment d051bf1cb82fc566f5050df83e60e624f6d7e49a 뒤 backend a14180ade1d71752bf77641650dde3541a7d7194가 총 118-case ordered SQL을 고정했다. fresh Supabase에서 lint와 DB01-08을 통과한 뒤 현 production이 JSON number referenceId를 ->>로 문자열화해 수락하여 exact P01-DB-EFFECT-REJECT accepted non-string-reference RED가 났다. 성공 mutation은 exception subtransaction에서 rollback됐고 disposable DB는 제거됐다. 독립 감사 두 건은 blocker/medium 0; production은 b63f8eb61e08dddd65bf8f80139c81931eade8ab 그대로다. 이후 production 후보 감사가 Unicode parity medium을 찾았다. application str.strip()은 29개 whitespace code point를 거부하지만 118-case 기준과 ASCII-only SQL 후보는 NBSP U+00A0 등을 빠뜨렸다. acceptance를 payload 174 + scope 290, 총 534 case로 상향하고 ASCII 후보는 커밋하지 않는다. 이 amendment와 새 executable RED가 다음 production revision보다 먼저 와야 한다. Unicode criteria assembly 568ae08c5e41ae530b4ae67bf9315ddfb881b396 뒤 backend f3cdf330ad9f44036f21894e0400365be3652153가 29-code-point matrix를 고정했다. fresh lint와 DB01-08 뒤 ASCII 후보가 exact P01-DB-EFFECT-REJECT accepted canonical-expected-reference-u001c-leading RED를 냈고 setup과 mutation은 rollback됐다. 두 독립 감사는 blocker/medium 0, disposable DB는 제거됐다.

DB09 final production 243a674ed5ad4e456e0c8cb55ca50ed9127cbe96은 여섯 JSON field의 raw type을 text 추출 전에 검사하고, Python 3.13 str.isspace()와 동일한 29개 code point를 scope 5개와 nullable payload text 3개의 양끝 canonical 경계로 사용한다. canonical cross-scope miss는 raw no-row 오류 대신 exact typed scope mismatch로 닫고 기존 command/effect lock, null-safe CAS, 빈 search_path, service-role 전용 권한은 유지한다. fresh tracked Supabase에서 public schema lint 0, DB01-09와 DB09 534 case, outer rollback을 통과했다. 네 authority race는 각각 winner=1 exact-loser=1 partial=0이고 helper/disposable container는 남지 않았다. 같은 revision은 Python 207 passed, Ruff check/format, Tach exact dependency/interface/external diagnostic 0을 통과했다. Vulture 3건은 Protocol signature false positive라 삭제하지 않았다. 최종 독립 감사 두 건 모두 blocker/medium 0이다. DB09 persistence만 GREEN이며 P01 전체는 계속 RED다.

DB10 기준은 제품 변경 전에 고정한다. completed revision 6과 repairable revision 5 두 lineage가 exact scope/result로 최초 finalize되면 accepted/current는 같은 idempotentReplay=false payload로 한 transaction에 기록되고 revision만 각각 7, 6으로 한 번 전진한다. strict result는 contract 918d797c578df43edc6697a85ab3016409bb75ee의 closed 25-key schema, closed five side effects, nullable closed repair shape에 묶인다. completed는 null repair와 exact profile/configure/resend action set, repairable은 pinned repair metadata와 inspect singleton을 가진다. 이미 accepted인 exact payload는 original expected revision으로 다시 호출해도 저장을 바꾸지 않고 delivery replay만 true; 관계/effect/action 배열은 canonical set normalization 뒤 비교해 order-only permutation도 replay이며, 의미가 다른 payload만 immutable 오류다. stale, 다섯 scope mismatch, malformed/raw replay payload, command/plan/claim/audit/journal/result mismatch, P02 manager-state 누수, outcome/repair/action 모순은 exact typed error와 whole-state 불변으로 거부한다. 동일 payload 동시 finalize는 first/replay 한 건씩, 다른 valid payload 동시 finalize는 winner/immutable loser 한 건씩만 허용한다. repair metadata는 coordinator-owned finalize 입력이며 최초 writer가 동결한다. 두 race는 smoke rollback과 독립된 committed lineage, target-row-lock readiness/release barrier, 전용 cloned disposable database와 always-run drop/baseline 검증을 소유한다. 이 atomic accepted/current와 response-loss replay는 token/fee 결과를 무시하는 레거시 boolean 성공 경로의 복제가 아니라 개선이다. 실제 HQ/비HQ 권한은 아직 actor gate가 아니다.

DB10 criteria assembly 5ee6aa6b282ef92978edb7ef658e5140985514c7와 contract 918d797c578df43edc6697a85ab3016409bb75ee 뒤 executable backend RED 56d87be190fa4897b80884eb382c369c5e1b6a7a를 고정했다. product migration blob은 5cf6c6a6002e365fb0280fdbe8c7631a7f91d702로 유지했고 DB09 prefix SHA-256도 6b25ce68293f595382962d93205c4c88a9a21c09cf2cc3ae90963317b2b25c06으로 exact 보존됐다. serial corpus는 rejection 2,094 + nullable-repair 유효 성공 1 + 최초 write 2 + replay 10, 총 2,107 case를 aggregate ledger로 고정한다.

pnpm run -s supabase:test:local-branch-onboarding-durable-store의 fresh RED 실행은 public schema lint와 DB01-09 SQL을 통과한 뒤 exact ERROR: P01-DB-FINALIZE missing finalize RPC, exit 3에서 순차 중단됐다. migration catalog의 Supabase CLI Tokio warning은 reset/lint/smoke를 막지 않은 비제품 경고다. teardown 뒤 container와 관련 /tmp artifact는 각각 0이다. 이 실행은 DB10 2,107 case나 두 finalize race의 통과 증거가 아니다. race는 첫 product RED를 닫은 production 후보에서만 실행한다. 최종 독립 감사들은 Blocker 0, Medium 0이지만 이는 RED harness 판정이다. DB11-13, UI, actual actor, screenshot/WebP는 계속 RED다.

후속 schema-hole 감사가 41개 result 문자열 path의 U+FEFF blank 우회를 찾았고 backend a7cdbf6d951082530569dc9989903214d5f9a7c4가 production보다 먼저 exact RED를 고정했다. production d40871109eb156c1f3ac53986f2ae310ddd4b3c9은 scope의 기존 29-code-point parity를 유지하면서 result schema whitespace만 보강했다. 최종 serial ledger는 rejection 2,135 + rollback-success 1 + first-write 2 + replay 10, 총 2,148 case다. fresh public schema lint와 DB01-10, outer rollback, 동일/상이 finalize race, 기존 네 authority race를 모두 통과했다. 두 finalize race는 각각 first=1 replay=1 revision-increment=1 partial=0, winner=1 immutable-loser=1 revision-increment=1 partial=0이며 source baseline은 exact 보존됐다.

cleanup ACK 간극을 닫은 harness는 a7b45a22d903f1b6669c1f996d6b2c06a561a9fe, Layer-first package marker 보강은 8a94ad7b6c77aac6e20eb6fed81d33d664558837이다. branch-onboarding Python은 207 passed, Tach diagnostic은 0, focused Vulture 세 건은 Protocol false positive다. clean HEAD 전체 5,663 passed, 1 failed의 유일한 실패는 DB10 이전 전역 Supabase validator가 auth.role() 문맥과 다수 hardened SECURITY DEFINER를 구분하지 못하는 별도 platform gate다. 최종 contract/security/race 독립 감사 모두 Blocker 0, Medium 0; 이 문단은 DB10 gate의 historical GREEN 기록이다. 이후 DB11까지 GREEN으로 승격됐고 DB12-13, provider/interface/orchestration/UI/actual actor/screenshot/WebP는 계속 RED다. 온라인 배포와 custom image build는 없었다.

P01 DB11 repair 기준

DB11은 새 repair API를 만들지 않고 기존 side-effect transition RPC의 non-null current 분기를 연다. DB10 repairable accepted/current revision 6에서 authorization, manager membership, fee, manager invitation 순으로 네 transaction을 단조 완료해 command revision 10과 completed current를 만든다. invitation delivery는 public contract의 sent 3-action 규칙과 repair-pending inspect singleton이 충돌하지 않도록 마지막에 둔다. 각 transaction은 선택 journal 한 행, strict current, command revision/allowed timestamp만 함께 전진한다. manager-membership 완료는 invited invitation row 하나만 만들며 active membership은 만들지 않는다. accepted POST snapshot, actor/HQ/key/command/branch, prepared identity claim, request/plan/fingerprint, audit와 다른 authority facts는 byte-identical이다. repair-pending current는 accepted와 같은 repairId를 유지하고 nullable nextRetryAt만 재스케줄한다. target effect와 command updated_at은 clock_timestamp() 기준으로 strict 전진하고 non-target timestamp는 불변이다. P02의 membership active/invitation accepted도 금지한다. Membership row 자체가 active authority이므로 DB11 동안 Data API direct mutation도 금지한다. authenticated와 service_role은 sanmopia_branch_memberships를 SELECT만 할 수 있고 direct service_role INSERT는 exact 42501이어야 한다. P02는 expected onboarding revision을 받는 narrow activation RPC와 acceptance audit/SpiceDB outbox 원자 경계를 별도 RED→GREEN한 뒤에만 열린다. criteria audit에서 application lineage validator가 changed current repair ID를 수용하는 반례와, generated TypeScript/Python validator가 sent invitation + unfinished repair-pending 조합을 수용하는 drift가 확인됐다. 첫 SQL RED 뒤 schema를 넓히지 않는 generated-client parity와 colocated application invariant를 각각 RED→GREEN한 뒤 SQL product를 열었다.

repair RPC에는 replay flag가 없다. 이미 소비한 transition의 old revision 재호출은 기존 DB09 계약대로 exact 40001이다. P01-exact-replay는 repair 완료 뒤 original DB10 accepted payload를 다시 finalize해 immutable repair-pending accepted + delivery replay true를 받고, completed current/journal/revision/ timestamp가 전혀 바뀌지 않음으로 검증한다. 동시 repair 두 후보는 command-row barrier 뒤 winner 1, exact CAS loser 1, revision increment 1, accepted unchanged, partial 0이어야 한다.

criteria가 executable SQL과 production보다 먼저다. 첫 backend RED는 valid authorization retrying → completed와 full current를 기존 RPC에 제출하고 현재 production의 exact 0A000 branch onboarding transition requires pre-acceptance state 및 whole-state 불변을 확인한 뒤 P01-DB-REPAIR complete-retrying-authorization returned 0A000 / branch onboarding transition requires pre-acceptance state sentinel로 멈춘다. DB12 scoped GET, DB13 cleanup, providers, interfaces, orchestration, frontend, actual actor와 screenshot/WebP는 열지 않는다. 따라서 상단 P01 상태는 계속 RED다.

실제 backend 82568de35df5099c429b5261df33bba3befd9ab9는 product migration blob ac31182989298d47a8199e5b37a9522562414570을 바꾸지 않고 위 single probe를 append했다. fresh Supabase lint 0과 DB01-10/DB10 serial 2,148 case 뒤 exact sentinel이 재현됐고, 전후 전체 authority/timestamp는 불변이다. 두 독립 감사는 Blocker 0, Medium 0; DB11 full corpus/race는 실행되지 않았다.

generated-client parity는 test-only RED 88a0688e68532cf14975b85b90947da351d00987, minimal product e16c642d39d879fe71b27d2edc52fb1ac281bf1f, tracked artifact 1f56d28b31a0a5f16045e41bb4555e7eb20e3745 순서로 닫았다. canonical JSON Schema/OpenAPI는 불변이다. sent와 accepted 두 반례, focused TS 7, Python 14, 전체 Jest 431, Python 37, layout/lint/build, Vulture 100% confidence 후보 0, 독립 Blocker 0 Medium 0을 확인했다.

application repair lineage는 test-only RED 5d3cc793671e9da547fb3449cffccc7821d559f3에서 changed repairId가 DID NOT RAISE임을 증명했고, 같은 ID의 timestamp/null nextRetryAt 변경은 허용 기준으로 함께 고정했다. product 60053a89240bbf3a5d4ec7fdad97cd6ce635d2b0은 application snapshot lineage에 stable repair ID만 강제한다. exact 1, focused 58, branch-onboarding 210, Ruff, Tach exact/interface/external 진단 0이 통과했다. Vulture 100% 후보 5는 모두 durable-store Protocol 인자로 확인해 삭제하지 않았다.

DB11 SQL은 test-only backend a49915c → 793891d → c6f8128 → 659942c → 53ff351 뒤 product c23c5bb5e235e71432a611510d3ce9a785b567d6로 닫았다. membership SELECT-only authority amendment c2d8d70은 product보다 먼저 accepted 됐다. Supabase CLI selected-migration reset, public schema lint 0, DB10 2,148 + DB11 1,571 = 누적 3,719 serial case와 outer rollback이 통과했다. 실제 두-session repair race는 winner 1, exact 40001 loser 1, revision 6 → 7, current/journal atomic 1, loser partial 0, invitation leak 0이다. Python 211 passed, Ruff/Tach/Vulture diagnostic 0, product 및 criteria 독립 감사 Blocker 0 Medium 0이다. 최종 fresh canonical gate도 public schema lint [], serial corpus, DB10/DB06/DB11/DB07 race와 disposable teardown을 다시 통과하고 P01 branch onboarding durable-store local Supabase acceptance passed scope=full을 반환했다. image pull, custom build, 온라인 배포는 없었다.

DB12는 assembly criteria f3f7124cf3accad1fe28ec6a97bf74f3015789b2 뒤 backend RED 5ca37d81389d24c02308f9149113def690b8680a → 26-case corpus c4b1fdac7b6b89424642c03335b84b5d38b22ab8 → initial GET ef1a97647947e37a46ff958a1933e8d779f8a0c1 순서로 열었다. 독립 감사에서 command의 mutable accepted payload가 자기 provenance를 증명하던 결함을 발견해 hardening RED ab386921945868b5a733e3bb00954de0e634fc86 뒤 product 3d2cc841ddb0abc06a2e963c67640854eda59996가 private append-only accepted receipt와 inspect/start/transition/finalize/GET guard를 추가했다. 새 public surface는 scoped GET 하나뿐이다. Application/adapter U+FEFF 불일치도 RED 448c326b9355ee429b00bb45cfd986c74c3d7880 뒤 final 264f1baea39acdbc9982bddbb4bf799ca01de0a6에서 SQL과 맞췄다.

최종 fresh Supabase gate는 exact 26 = 1 catalog + 2 success + 5 not-found + 18 rejection, public schema lint [], outer rollback, DB10/DB06/DB11/DB07의 실제 경합, exact source/clone teardown과 full-scope sentinel을 통과했다. Python 218 passed, Ruff/Tach 0; Vulture 3건은 required Protocol parameter false positive다. 최종 제품 감사 Blocker 0, Medium 0이다. DB12만 GREEN이며 실제 actor, screenshot/WebP, provider/interface/orchestration/frontend는 아직 RED다.

현재 다음 작업

P01·P02·P03은 각 canonical evidence pack에서 PASS다. 현재 gate는 P04-mother-reservation-chat이다. 현재 Backend pin은 4f1eea71a240a6381c8695749d572cd85a21baeb이다. 그 조상 8b214509와 8e37ab8a는 selected regional-support를 browser/option payload 금액이 아니라 exact approved regional-benefit fingerprint와 현재 preparation region·branch·price-version authority로 재검증한다. Fixed/rate/component 공식은 Pricing Settlement domain에서 계산하고 quote·customer credit·charge handoff revision에 같은 금액을 기록한다. 8b214509는 complete accepted decision을 internal-only mapping에 동결하고 consumer-owned reservation-booking application contract로 exact 검증해 booking command까지 전달한다. Discount-only 선택은 resolved이며, 서비스일/종료일/own-price 효과는 non-zero이면 계속 fail-closed다. 현재 pin은 final-review missingFactPaths에서 disabled/capability reason을 파생하고 support 판단을 별도 missing fact로 추적해 해결된 booking/payment authority가 오래된 차단 사유로 남지 않게 한다. 더 이전 조상 7e2b86db9d21c8d483957f0888620b06b1eb03ad은 verified Auth subject를 Member Management의 exact account-link proof로 바인딩해 P04와 booking이 같은 mother/member/profile/revision authority를 소비하게 하고, Pricing Settlement의 typed PaymentActorContext와 immutable actor snapshot lineage까지 같은 proof에 결속한다. 그 직전 pin 01ce8a5742691118cebeb9b2c2d1cf92fb7e1639이 account-link proof를 열었고, 665bf7e1be7b38648e15dd9e3daa09bbea4f546d은 stale expected revision을 mutable catalog authority 조회보다 먼저 domain SSOT로 검사해 503으로 새는 경로를 actual 409로 닫았다. 그 조상 b8b5d8ea2bb2edfe1057ec457ec142db090156ff와 8e5465cc5da0969e0f0af79c19c326071627c4cf에서 실제 local GoTrue/PostgREST와 production Supabase HTTP adapter를 사용해 owner mother, foreign mother, branch operator, caregiver, family member 다섯 actor를 검증했다. 미인증 401, 비산모 create 403, 타 산모 draft read 403, typed validation 422 무변경, stale revision 409, create/PATCH exact replay, 열 단계와 revision 1 → 11, teardown 뒤 Auth/draft/source/contribution residue 0, sponsorship·delegated-payment production catalog의 option 2개와 extension-source option 1개의 opaque selection reference를 확인했다. raw grant, delegation, reservation id는 내부 authority lineage에만 남는다.

현재 pin은 Layer-first Security Audit context와 P04 consumer port를 추가해 draft recovery success의 exact revision과 missing bearer/invalid scheme/session/not-found/ownership/ expired/inactive denial을 durable ledger에 기록한다. Raw bearer, resume key, actor subject, draft reference는 저장하지 않고 SHA-256 digest만 남긴다. Disposable full migration chain에서 service-role exact INSERT+SELECT, update/truncate 및 anon/authenticated 42501, privileged update/delete 55000, forbidden raw columns 0을 확인했다. Full Python 7,018, Tach affected 3,093/3,904 deselected, exact/external/architecture, Vulture confidence 100을 통과했다. 새 Chromium/screenshot/WebP/deploy는 실행하지 않았다.

현재 pin은 승인된 voucher-plan population에서 source-order와 실제 consume_type_value를 읽는 service_offering.voucher_income_types production publisher를 추가했다. Supabase CLI migration, 승인 population DB smoke, missing-axis fail-closed와 rollback 뒤 voucher source/population/revision 0/0/0을 확인했다. 또한 authenticated owner의 유효한 promotion entitlement만 읽고, browser에는 hashed selection reference만 노출하며 raw entitlement UUID는 내부 authority에만 보존하는 production publisher를 trusted preparation에 연결했다. 실제 PostgreSQL smoke로 owner 격리, proven-empty catalog, redemption/revision 변경 뒤 frozen authority 철회를 확인했다. 새 5-actor/Chromium 실행을 했다고 주장하지 않는다. 최신 pin은 private-care workbook의 20개 정규 entry를 duration 4개, work schedule 2개, service option 10개로 투영하고, 세 catalog publisher를 등록했다. caller가 published_at을 주입하던 경로를 제거하고 Supabase RPC가 publication time·canonical fingerprint를 원자적으로 소유한다. 실제 DB smoke는 대표 entry 2개로 최초 publish, 동일 fingerprint replay, published batch/entry 변조 거부, registry 22/26, rollback residue 0을 증명한다. 이 smoke는 실제 workbook 20행을 운영 batch로 발행했다는 증거가 아니다.

현재 pin은 service_offering.voucher_delivery_rank_and_workforce도 승인된 단일 voucher population에서 발행한다. PHP 숫자 id 감산·사태아 switch·loader 별칭 땜질을 복사하지 않고 stable delivery code 8개와 한 domain label/workforce policy로 바꿨다. guarded RPC, Layer-first query/adapter/publisher, trusted preparation binding과 실제 DB 권한/source-order smoke가 registry 22/26을 증명한다. 최종 source 확인 중 발견한 voucher parser P:W 오프셋은 named B:X column contract로 교정했다. pinned actual workbook은 198/198, issue 0, baby group 4, delivery code 8로 ready_to_publish다.

현재 pin은 additional_services.rental_options를 구버전 live DB numeric id 대신 stable key 5개와 승인 revision으로 발행한다. PHP 화면·상수·관리자 엑셀 경로를 함께 대조해 유축기 장비료 15,000원, 예약당 왕복 배송비 최대 1회 10,000원, 유축기만 지점 확인이라는 규칙을 고정했다. 예약 선택과 정산 계산은 동일한 RentalEquipmentChargeCatalog를 읽는다. 실제 DB smoke는 source 순서, catalog/source-evidence fingerprint, service-role-only RPC, 불변성, registry 22/26, rollback을 통과했다. full regression은 6,779 passed다. 이는 새 5-actor/Chromium/WebP run이 아니다.

현재 pin은 caregiver_matching.priorities도 구버전의 0/1/2 숫자 코드, 반복 select markup, 삭제 후 순차 insert를 public 권위로 복사하지 않고 발행한다. source-reviewed stable key는 postpartum_care, newborn_care, household_care이고 한 domain catalog가 ordered_unique, 최대 3개, matching priority 변환을 소유한다. guarded RPC와 실제 DB smoke는 source 순서, catalog/source-evidence fingerprint, service-role-only 권한, 불변성, registry 23/26, rollback을 통과했다. full regression은 6,796 passed, DB lint error 0, Ruff/Tach/Vulture gate도 통과했다. 이는 새 5-actor/Chromium/WebP run이 아니다.

현재 pin은 caregiver_matching.personalities도 구버전 numeric DB id와 blind pair grouping을 공개 계약에 복사하지 않고 발행한다. source-reviewed 6문항·12선택지는 question.answer stable key를 사용한다. 한 domain catalog가 six-by-two shape, exactly_one_per_question, source order, 기존 CaregiverPersonalityAnswer 변환을 소유한다. guarded RPC와 실제 DB smoke는 source anchor 7개, catalog/source fingerprint, service-role-only 권한, 불변성, registry 24/26, rollback을 통과했다. 원문의 오탈자·띄어쓰기 4건은 UI 땜질이 아니라 fingerprint에 포함된 명시적 normalization이다. full regression은 6,806 passed, DB lint error 0, Ruff/Tach/Vulture gate도 통과했다. 이는 새 5-actor/Chromium/WebP run이 아니다.

현재 pin은 contract_and_payment_preference.support_programs도 regional-benefit source authority로 발행한다. 완주군 지원은 legacy에서 주소 문자열, price version <= 3, 5일 차감·가산, DOM state로 흩어져 있고 영등포구는 2023-02-01 제거 뒤 stale 분기만 남아 있다. 새 구현은 RegionalBenefitRule의 region code, price-catalog version window, 승인 revision, source evidence를 SSOT로 사용한다. v4+는 검토된 empty catalog이고 v1~v3은 정확 option row/price authority 없으면 fail-closed다. 실제 DB smoke는 source anchor 7개, service-role-only RPC, 불변성, registry 25/26, rollback을 통과했다. full regression은 6,816 passed다. 이는 새 5-actor/Chromium/WebP run이 아니다.

현재 pin은 caregiver_matching.recommendations도 existing frozen recommendation-set authority에 연결했다. Legacy raw MANAGER_ID_PK hidden input/carousel data-id는 browser option으로 복사하지 않고, opaque selectionReference와 decision authority revision만 catalog에 노출한다. 실제 local PostgreSQL migration으로 production publisher registry는 26/26이고, exact-26 materializer smoke, catalog smokes, DB lint error 0, Ruff/Tach/Vulture, full regression 6,820 passed를 통과했다. 이는 새 5-actor/Chromium/WebP run이 아니다.

Backend d29f6b7a는 그 동결 catalog를 final-review caregiverCandidateDecision에도 결속한다. Decision authority reference/revision과 specific opaque selection이 현재 exact catalog에 일치할 때만 caregiver missing/invalidation을 제거한다. Stale revision, 중복 reference, disabled/malformed option은 fail-closed다. 공개 contract 검증과 focused 6 passed, full 6,853 passed, Ruff/Tach를 통과했다. 이는 새 actor/Chromium/WebP run이나 global readiness 증거가 아니다.

Backend 7a345e7b는 support/promotion current catalog가 둘 다 존재하고 두 요청 목록이 비었을 때만 empty support decision을 확정한다. 요청이 있거나 catalog가 빠지면 0원 추정 없이 invalidation을 유지한다. Focused 8 passed, full 6,855 passed, Ruff/Tach/Vulture를 통과했다.

Backend 867ba51f는 선택된 promotion을 Pricing Settlement 권위로 해석한다. Frozen catalog revision을 authenticated owner의 live catalog revision과 다시 대조하고, browser 선택 순서가 아닌 catalog source order로 여러 쿠폰을 적용하며 customer payable을 0 아래로 내리지 않는다. 할인된 payable과 customer credit은 final-review quote, charge handoff, payment preparation, atomic waiting obligation 입력에 동일하게 전달된다. Legacy 다중 쿠폰 합산과 0원 floor는 Reservation_model.php:1200-1205, :1261-1262, pre_reservation_payment.php:123-127, modal_change_payment.php:5-13에 고정했다. 선택된 regional support는 pricing-owner amount rule이 없으므로 base quote/handoff도 만들지 않고 fail-closed다. Full regression은 6,864 passed; Ruff, 변경 9파일 format, Tach exact/external, 변경 production Vulture confidence 100 finding 0을 통과했다.

Backend 8e37ab8a는 위 fail-closed 경계를 한 단계 전진시켰다. Selected option은 exact current support catalog에 있어야 하고, catalog SHA-256 revision, persisted preparation의 region/branch/price-version, approved rule count/order/effective window를 모두 다시 통과해야 한다. 가격은 quote component map과 regional-benefit fixed/rate/component formula만 사용하며 browser가 금액을 보낼 필드는 없다. 계산된 할인은 promotion보다 먼저 적용되고, promotion은 남은 payable 안에서만 적용된다. Regional/promotion decision revision은 charge handoff fingerprint에도 포함된다. 서비스일/종료일/own-price 효과 또는 accepted booking impact materializer가 필요한 선택은 계속 partial이다. Full regression 7,033 passed, Tach affected 125 passed/6,887 deselected, Tach dependency/interface/external 진단 0, Ruff와 Vulture confidence 100 후보 0이다. 현재 v4+ 운영 authority는 proven-empty이므로 새 산모 browser/WebP 증거를 만들지 않았고 배포도 하지 않았다.

Backend 8b214509는 selected regional-benefit accepted-impact의 discount-only 내부 인계를 닫았다. Complete benefit/component/policy/source/settlement/effect/decision lineage를 public projection이 아닌 internal booking mapping에 보존하고, reservation-booking application contract가 public regional-support decision, accepted quote credit line, charge pricing revision, unique source options, catalog revision을 exact 검증해 RegionalBenefitDecision을 booking command에 전달한다. Cross-feature domain import 없이 consumer-owned Protocol을 사용한다. Targeted 14 passed, full 7,039 passed, Tach dependency/interface/exact/external 진단 0, Ruff PASS다. Vulture confidence 100 후보 1건은 Protocol 인자의 실제 구현·전달·호출을 확인한 false positive다. 현재 운영 v4+ catalog가 proven-empty라 실제 non-empty Supabase outbox→booking→settlement, browser/WebP, deployment 증거는 추가하지 않았다.

Backend 4f1eea71은 static blocker tuple을 제거하고 supportAndDiscountDecisions를 포함한 ordered missing-fact SSOT에서 authoritative_projection_partial, booking_handoff_missing, payment_handoff_missing, contract_acceptance_missing을 파생한다. 모든 기술 권위를 채운 fixture는 serviceContract.acceptance와 계약 차단만 남긴다. Targeted 14 passed, full 7,040 passed, Tach affected 457 passed/6,562 deselected, architecture diagnostics 0, Ruff PASS다. Vulture의 evaluated_at 3건은 실제 구현·호출되는 Protocol parameter다. Frontend 1c7bd8b2는 네 reason code를 exact Korean copy로 고정했고 91 files / 580 tests, lint, Astro 7 check/build를 통과했다. 새 actor/browser/WebP/deploy는 실행하지 않았다.

Backend b7894b89는 confirm transaction이 만든 durable outbox의 기존 claim/complete/fail RPC를 typed production adapter와 runtime에 연결한다. Claim은 DB 순서와 attempt-count CAS를 보존하고, complete/fail은 같은 attempt와 단일 반환 row만 허용한다. Focused 6 passed, full 6,868 passed, Ruff/Tach exact/external을 통과했다. 이는 booking command 변환이나 workflow 실행 완료가 아니다.

Backend 0676b50e는 reviewed stable selection을 실제 booking command가 요구하는 legacy 실행 tuple로 해석하는 버전된 application port를 runtime에 연결한다. Offering, private duration/work schedule 또는 voucher service-day, exact price entry, authoritative service-day count가 모두 맞는 단 하나의 source-owned option만 허용한다. Label/order/opaque value/reservation_amount_hint는 authority가 아니다. 결과 numeric ID는 공개 final-review가 아니라 fingerprint에 포함되는 별도 internal projection에만 저장된다. Missing/ambiguous lineage는 partial 유지다. Full 6,876 passed, Ruff, Tach exact/external, changed-production Vulture confidence 100 finding 0이다. Outbox consumer와 실제 booking workflow 실행은 아직 미완이다.

Backend 60334ee0는 internal booking mapping에 local start/end time, IANA timezone, working-time policy revision을 필수로 추가했다. Legacy terms의 출퇴근·토요일·입주·협의 조정 규칙 때문에 consumer가 working_type_id로 시간을 추측하지 않는다. Assembly 517cd210 stage seed는 stable selection/price/time lineage를 함께 제공한다. Missing/invalid timezone 또는 time lineage는 fail-closed다. Full 6,876 passed; seed 실행, outbox consumer, workflow 실행, browser/WebP/deploy는 미완이다.

Backend 384a97a6는 frozen caregiver recommendation의 opaque selection을 Caregiver Matching owner에서 재검증하고 internal execution ID로 해석한다. Specific selection은 exact opaque reference, backend recommendation은 frozen rank one을 사용한다. Current owner/request/decision/revision이 모두 일치하고 candidate_profile_id가 canonical positive integer일 때만 internal booking handoff에 기록한다. Public catalog/final-review는 계속 opaque-only다. Stale/unknown/ambiguous/non-numeric은 partial 유지다. Full 6,881 passed; outbox command translation/workflow/browser/WebP/deploy는 미완이다.

Backend 045c145b는 confirmed draft를 active final-review query로 다시 읽는 모순을 제거했다. Service-role-only RPC가 processing outbox의 exact attempt, command, draft, booking request, projection revision, reviewed fingerprint를 대조한 뒤 immutable accepted projection만 반환한다. Migration은 repository에만 있고 어떤 Supabase 환경에도 적용하지 않았다.

Backend d23b1842는 accepted projection을 기존 booking workflow에 연결한다. Named orchestration이 branch, branchId 포함 versioned execution mapping, selected caregiver, local time/IANA timezone, quote, payment, coverage를 current operational context와 재대조해 public booking command를 만든다. Bearer-protected internal job은 pending outbox를 claim하고 workflow exact replay까지 start한 뒤 같은 attempt를 CAS complete/fail한다. Focused 15 passed, full 6,900 passed, Ruff, Tach exact/external PASS다. Vulture confidence 100은 기존 Protocol parameter false positive 5개뿐이다. 이 pin 당시에는 ADR-032 legal acceptance, accepted offering/consumer-impact side-effect assembly, migration 적용, real DB actor/browser/WebP/deploy가 미완이었다.

Backend be9ec4f9는 accepted service occurrences를 existing booking ServiceTermPlan으로 변환한다. Quote service-day count, contiguous sequence, strict date order, accepted date range/end date, exact calendar profile/policy revisions가 모두 맞아야 한다. 따라서 booking workflow의 기존 occurrence-ledger persistence를 재사용하며 legacy numeric ID로 날짜를 재계산하지 않는다. Focused 25 passed, full 6,902 passed, Ruff, Tach exact/external, changed-file Vulture confidence 100 PASS다. 이 pin 당시에는 실제 DB workflow 실행과 accepted offering availability / consumer-impact side-effect assembly가 미완이었다.

Backend b1beee53는 failed 또는 15분 이상 stale processing인 exact outbox attempt만 pending으로 복구한다. Attempt count는 다음 claim을 위해 보존하고 source status/claimed time/error/reason/actor와 delivery snapshot을 immutable audit에 남긴다. Advisory lock, attempt/status CAS, stored-result idempotent replay를 적용했고 bearer internal route는 안전한 404/409/503만 노출한다. Focused 60 passed, full 6,917 passed, Ruff, Tach exact/external, changed-production Vulture confidence 100 PASS다. Migration 20260718124500은 scoped disposable PostgreSQL 17.6에 verbatim 적용하고 Supabase CLI schema lint error 0을 확인했지만 local/stage/production 적용이나 clean full-history replay 증거는 아니다.

Backend fcad4c50는 accepted offering availability와 consumer-impact assembly를 로컬 booking workflow에 연결한다. Service-offering catalog contribution은 offering key, availability state, handoff kind, unavailable reason, message key, policy revision, source evidence를 fingerprint에 포함한다. Final-review materializer는 exact enabled selected option, full-reservation handoff, 정확한 policy source revision만 internal booking mapping에 동결하며 공개 final-review contract는 늘리지 않는다. Accepted-handoff translator는 같은 lineage를 재검증하고 application-owned 단일 builder로 daily_report, settlement, service_calendar 세 consumer fact를 만든다. 기존 public booking API도 같은 builder를 재사용한다. Affected 123 passed, full 6,919 passed, Ruff, Tach exact/external PASS다. Changed-production Vulture confidence 100은 새 finding 0, 기존 Protocol parameter false positive 15건이다. 이 slice에는 migration, 실제 Supabase consumer E2E, actor/browser/WebP/deploy가 없다.

Backend 3ac941d5는 terminal PATCH와 exact replay의 final-review catalog scope를 저장된 current draft revision에 고정한다. Layer-first application port 뒤의 named orchestration이 current preparation authority로 26개 contribution을 materialize하고 owner-scoped provider에서 snapshot을 다시 읽은 뒤에만 projection을 만든다. Pre-PATCH snapshot 재사용은 제거됐고 cross-owner는 write 전에 거부된다. Authority 부재는 fail-closed이며 exact replay가 준비를 재시도한다. Focused 21 passed, Tach affected 411 passed, full 6,921 passed, Ruff/Tach PASS다. Vulture confidence 100의 13건은 기존 Protocol parameter 후보다. 현재 preparation authority를 만드는 source adapter 0/5와 모든 draft activation, 실제 Supabase actor/browser/WebP/deploy는 여전히 미완이다.

Backend 026a8ba4는 preparation reservation_state source를 기존 customer_action_availability SSOT에 연결해 source adapter를 1/5로 전진시킨다. Revisioned mapping이 raw legacy status를 lifecycle로 해석하므로 active pre-reservation과 취소된 과거 flag를 구분한다. 연장은 owner catalog의 exact opaque selection만 인정하고 raw reservation id는 공개 decision에 포함하지 않는다. Runtime은 extension publisher와 같은 query handler를 공유한다. Focused 11 passed, Tach affected 116 passed, full 6,925 passed, Ruff/Tach PASS, Vulture confidence 100 새 후보 0이다. 나머지 네 source와 record-authority activation, actual Supabase actor/browser/WebP/deploy는 미완이다.

Backend dcced6ad는 두 번째 preparation source인 branch_coverage를 runtime에 조립해 source adapter를 2/5로 전진시킨다. 활성 core branch와 활성 office lifecycle을 모두 만족하고 positive source_branch_id가 있는 후보만 기존 revisioned service-area policy로 평가한다. available 후보가 정확히 하나일 때만 branch profile과 legacy compatibility id를 동결하며, 후보 0개/복수, 상담전용, 불가, 본사내부, 중복 id는 fail-closed다. Draft나 후보 행 순서는 branch authority가 아니고, 고객 주소 원문은 lineage에 복사하지 않는다. Focused 10 passed, Tach affected 603 passed/6,308 deselected, full 6,932 passed, Ruff/Tach PASS, Vulture confidence 100 새 후보 0이다. 나머지 세 source와 record-authority activation, actual Supabase actor/browser/WebP/deploy는 미완이다. SQL migration은 추가하지 않았다.

Backend 7af3496b는 세 번째 preparation source인 service_offering_policy를 runtime에 조립해 source adapter를 3/5로 전진시킨다. Draft가 선택한 exact serviceOfferingKey와 catalog/branch/region/business-date가 일치하는 effective row 하나만 허용한다. Service program, service-type detail code, policy revision, inclusive pre-reservation day threshold는 source_reference.catalog_preparation_policy의 필수 DB 메타데이터이며 label, row order, legacy id에서 추론하지 않는다. Missing/ambiguous/stale metadata와 selection drift는 모두 fail-closed다. Source-row UUID, catalog version, policy revision, updated_at, evidence key가 lineage fingerprint에 포함된다. Concrete Supabase adapter는 main에서 application port로 주입된다. Targeted 16 passed, Tach affected 254 passed/6,668 deselected, full 6,943 passed, Ruff/Tach PASS, Vulture confidence 100 새 후보 0이다. pnpm Supabase CLI 2.109.1은 준비됐지만 local stack은 미기동이다. Price version, voucher criteria, record-authority activation과 actual Supabase actor/browser/WebP/deploy는 미완이다.

Backend 0809dc25는 네 번째 preparation source인 price_catalog_version을 runtime에 조립해 source adapter를 4/5로 전진시킨다. 구버전 예약이 실제 저장하던 PRICE_VERSION_LIST_ID_FK는 label이나 연도 순번이 아니라 price import batch에 명시된 positive source_price_version_id로 보존한다. Supabase CLI-created migration은 해당 field를 추가하고 published 전환 시 누락을 거부한다. Pricing owner query는 requested program과 desired start date에 유효한 published batch exact-one만 허용하고 voucher는 같은 batch의 unique price_version_key를 추가로 요구한다. Missing/overlap/conflicting key/future publication/drift는 fail-closed다. Focused 50 passed, pricing/Supabase 184 passed, Tach affected 731 passed/6,205 deselected, full 6,957 passed, Ruff/Tach PASS, Vulture confidence 100 새 후보 0이다. Local Supabase stack이 없어 migration apply/actor DB smoke는 미실행이며, 남은 source는 voucher criteria 하나다. Record-authority activation과 actual Supabase actor/browser/WebP/deploy도 미완이다.

Backend 68ce17dc는 마지막 preparation source voucher_plan_criteria를 runtime에 조립해 source composition을 5/5로 닫는다. Persisted birth.baby_types option과 exact quantity bounds로 baby classification을 검증하고, approved voucher delivery/workforce와 income catalog의 exact option key를 같은 source revision/population/price batch/version으로 묶은 뒤 exact published voucher-plan revision을 재검증한다. Label/prefix/legacy-id 추론, unknown option, baby-count conflict, population 또는 price drift, ambiguous selection, future publication은 fail-closed다. Focused 140 passed, full 6,967 passed, Ruff/Tach PASS, Vulture confidence 100 새 후보 0이다. 실제 DB/browser/WebP/deploy는 새로 실행하지 않았다. Source 완료와 record activation을 구분한다. v2 persistence가 evaluation date와 voucher quote date를 같게 묶는 현재 상태에서는 미래 서비스 시작일 quote를 기록할 수 없으므로, 날짜 위상 migration과 actual Supabase record 검증 전 P04는 RED다.

Backend 0934462d는 그 날짜 위상과 record activation의 로컬 코드 경계를 닫는다. V3 RPC는 evaluated_on을 DB-owned Asia/Seoul 현재 영업일에, quoted_on을 persisted desiredServiceStartOn에 각각 결속하고 persisted offering/baby facts와 five-source lineage를 재검증한다. Terminal PATCH와 exact replay는 source resolve → v3 authority record → exact-26 publish → owner-scoped reload 순서로 진행하며 record 실패 시 뒤 단계가 실행되지 않는다. Scoped PostgreSQL 17에서 v1→v2→v3 apply와 미래 견적일 actual record/load를 확인했다. Focused 65 passed, 예약 생성 영역 425 passed, Tach affected 229 passed/6,727 deselected, full 6,977 passed, Ruff/Tach/Vulture PASS다. Local Supabase stack은 없었으므로 migration 적용, actual actor/browser/WebP/deploy는 아직 증명하지 않았다. P04는 RED다.

Backend ba622266은 산모가 검토한 contact, birth/babies, pet facts를 exact catalog label·revision·authority lineage와 함께 fingerprinted internal accepted customerIntakeSnapshot으로 동결한다. Disabled/missing/ambiguous option, baby count/type 불일치, malformed pet separation은 fail-closed다. Accepted booking translator는 이제 current operational context의 반려동물 상태를 다시 읽지 않고 이 accepted snapshot만 소비하므로 검토 이후 drift가 booking command를 바꾸지 못한다. 해당 pin의 당시 13-section public final-review에는 이 전체 snapshot이 표시되지 않았다. Focused 23, application 127, orchestration 79, adapter 23, Tach affected 437/6,523 deselected, full 6,981 passed, Ruff/Tach PASS다. Vulture confidence 100의 3건은 required evaluated_at Protocol parameter 오탐이다. Migration, actual Supabase, actor/browser/WebP/deploy는 실행하지 않았다. P04는 RED다.

Contract 0f5f333, backend 5be42194, frontend fb69309는 같은 frozen customerIntakeSnapshot에서 public-safe customerIntakeDisplaySnapshot을 만들고 14-section final-review 계약과 화면에 결속한다. 공개 payload는 생년월일·비상연락처, 출산/아기, 반려동물/분리 사실과 stable key·서버 label만 포함하고 raw authority 및 catalog lineage는 제외한다. Final review의 세 정보 카드 안에서 바로 원래 chat step을 편집할 수 있다. 저장 뒤 입력 카드는 그대로 보존하고 서버 downstream invalidation은 의존하는 파생 권위만 폐기한 뒤 exact revised final review를 다시 만든다. Contract TypeScript 486, Python 82, backend reservation-creation 430, Tach affected 438/ 6,523 deselected, backend full 6,982, frontend 575와 Astro check/lint/build가 통과했다. Vulture confidence 100의 17건은 required Protocol parameter다. 실제 Chromium desktop/mobile 39개 artifact는 customer-reservation-draft-chat-fb69309에 고정했지만 stateful mocked API이므로 actual Supabase actor/browser 증거가 아니며 P04는 RED다.

이전 partial final-review projection materializer pin에서는 마지막 writable PATCH가 완료되면 서버가 exact catalog snapshot을 기준으로 당시 13-section contract-valid projection을 Supabase record RPC에 기록한다. GET final-review는 recorder 부재 때문에 503으로 막히는 단계를 넘겼고, 실제 draft/catalog에서 산모 연락처, 자택/서비스 주소, service offering, duration, work schedule, 선택 토요일/공휴일 service occurrence, 추가서비스, 대여용품, 관리사 선택 mode, payment method 표시값을 채운다. 그러나 projection은 confirmation_ready=false이며 authoritative_projection_partial, booking_handoff_missing, payment_handoff_missing을 그대로 노출한다. Reservation-creation regression은 351 passed, full regression은 6,823 passed다. 최신 backend 121f786c은 current catalog-preparation authority, source branch profile, revisioned service-area policy를 query port와 orchestration bridge로 연결한다. 권위가 존재하면 exact→parent→시도 lookup, matched rule/depth, coverage profile, impossible-area veto, address fingerprint를 final review에 고정하고 coverage missing/invalidation을 제거한다. 권위가 없으면 partial missing을 유지하고 scope drift는 fail-closed다. 이어 calendar profile key와 raw rule key, current catalog의 구조화 serviceDayCount, effective Supabase profile revision, national/branch holiday를 기존 calendar domain에 연결한다. 해결된 경우 requested-date placeholder를 실제 billable occurrence/end date/policy fingerprint로 치환하고 plan/calendar missing과 invalidation만 제거한다. metadata/profile이 없으면 partial을 유지한다. affected context 회귀는 192 passed, full regression은 6,835 passed, Ruff/Tach exact/external/Vulture는 통과했다. 이어 voucher exact price entry 또는 private duration/work-schedule entry 교집합을 current effective Supabase publication과 결합하고 기존 pricing domain으로 quote한다. Exact 1개일 때만 price missing/invalidation을 제거하며 option catalog에는 금액을 복사하지 않는다. Full regression은 6,841 passed, price focused regression은 24 passed다. 이어 draft revision과 exact quote lineage로 pricing-owned charge snapshot handoff를 만들고 handoff missing fact를 제거한다. 이는 finalized booking snapshot이 아니며 atomic confirm 소비는 남아 있다. Current payment catalog와 quote amount는 payment preparation을 확정하고 unsupported method를 거부한다. Full regression은 6,847 passed, payment-preparation focused regression은 13 passed다. Backend 8e7b88bf는 이 두 projection을 재검증해 waiting obligation과 공개 handoff를 acceptance/outbox와 원자 기록한다. Full regression은 6,868 passed, outbox delivery focused 6 passed, atomic payable focused regression은 32 passed다. P04 disposable DB에 migration 적용과 DB lint error 0을 확인했지만 clean full-history reset은 local Realtime/bootstrap 결함으로 미완이다. 이는 새 5-actor/Chromium/WebP run이 아니다.

이전 5-actor 실행의 26개 catalog는 transport·authorization·persistence를 검증하기 위한 test-owned fixture였다. 현재 운영 DB publisher registry는 26/26이고 partial final-review projection은 일부 실제 draft/catalog 표시값을 바인딩한다. current preparation authority와 calendar authority가 모두 있는 경로는 terminal PATCH/replay에서 current revision exact set을 다시 준비하고 branch coverage와 service plan/calendar를 바인딩한다. Preparation source는 reservation state, branch coverage, service-offering policy, price catalog version, voucher-plan criteria 5/5까지 조립됐고 v3 date split과 terminal PATCH/replay record activation도 로컬 코드·scoped PostgreSQL에서 검증됐지만 actual Supabase migration과 actor별 persisted activation, real non-empty regional-benefit runtime proof, contract retained authority, legal acceptance, finalized booking snapshot, global readiness가 없어 confirmation-ready final review는 아직 아니다. frontend fb69309의 stateful mocked API Chromium은 desktop/mobile 열 단계 순차 공개, 새 현재 카드 focus/scroll, 완료 카드 편집, 서버 downstream invalidation, 409, 200 미완료, typed 422, 14-section final review의 retained intake 표시·카드 내부 수정과 완료 상태를 통과했고 provisional WebP를 남겼다. 이는 실제 Supabase 통합 증거가 아니다. 따라서 P04는 계속 RED/partial이다. 다음 구현 순서는 retained display를 legal/contract authority에 연결한 뒤 production final review, 실제 non-empty regional-benefit 선택과 booking handoff lineage, legal confirmation/booking handoff persistence·replay, single-chat Chromium/WebP, clean four-repository pin을 같은 run에서 검증하는 것이다. P05~P13은 계속 blocked다.

Backend b8b5d8ea는 disposable local Supabase DB, GoTrue, PostgREST와 production FastAPI transport로 위 5-actor 흐름을 다시 실행했다. Terminal PATCH는 current authority를 기록하고 production publisher 26/26을 실행해 exact catalog set과 한 final-review projection을 materialize한다. 결과는 completed step 10, revision 11, HTTP final review 200, exact authority section 14, internal retained-intake lineage 8, public lineage leak 0이다. 그러나 fixture source는 명시적인 test-owned authority이며 confirmationReady=false다. Branch calendar/service plan, service-offering availability decision, price quote, charge handoff, payment preparation, contract acceptance가 unresolved이므로 confirm을 실행하지 않았다. Full Python 6,986, Tach affected 6,689/276 deselected, Tach exact/external, Ruff, Supabase DB lint error 0을 통과했다. 새 Chromium/screenshot/WebP/deploy는 실행하지 않았다. P04는 계속 RED/partial이다.

Contract b487faf, backend 665bf7e1, frontend 4371660은 그 backend partial projection을 실제 browser 경계까지 연결했다. Pending quote의 빈 line은 readiness가 false이고 missing path가 priceQuote일 때만 public TypeScript validator가 허용하며, 초기 draft는 unset step을 null로 내보내지 않는다. Actual desktop/mobile Chromium은 owner GoTrue cookie, Astro production build/preview의 true same-origin proxy, production FastAPI/PostgREST/Supabase로 열 단계를 각각 완료하고 revision 11, final review 200, confirm disabled를 확인했다. 단일 현재 카드, 저장 후 focus/scroll, readable warning, horizontal overflow·console·page·failed request 0도 확인했다. Desktop 연락처 편집은 revision 12, retained input 10, derived invalidation 11, exact revised review reload를 통과했다. Actual 422는 현재 카드를 유지하고 persisted revision/input을 바꾸지 않았으며, actual stale 409는 blind PATCH 없이 explicit GET refresh 뒤 사용자가 확인해 revision 3으로 저장했다. Branch/caregiver actual create는 각각 403, draft card 0, safe authorization copy를 확인했다. Foreign mother의 owner-draft resume GET은 actual 403, test-owned missing-header resume GET은 actual 401이며 모두 draft card 0, safe copy, resume key purge를 통과했다. p04-live-browser-4371660의 공개 파일 45개와 manifest asset 44개에는 desktop/mobile success, desktop validation 422, mobile conflict 409, branch/caregiver create 403, foreign-mother/missing-header resume 403/401 animated WebP와 readiness/edit screenshot, redaction manifest가 있다. Source authority 일부는 test-owned이고 production source completeness, real non-empty regional-benefit runtime proof, legal acceptance, confirmation-ready confirm, clean four-repository pin, deploy는 미완이므로 P04는 계속 RED/partial이다.

Backend 35f67ff912d32c92e4772e60895bf1da45014437 current pin에서는 같은 실제 GoTrue/PostgREST/Supabase/FastAPI/Astro browser matrix를 재실행했다. p04-live-browser-35f67ff은 공개 파일 45개, manifest asset 44개, animated WebP 6개를 고정하고 desktop/mobile completed step 10, single-current-card, automatic focus/scroll, horizontal overflow 0, console/page/failed request 0, edit/reprojection, actual 422/409/403/401을 다시 통과했다. 이 run의 final review는 계속 confirmationReady=false이고 confirm disabled이므로 booking party snapshot 생성 경로를 browser에서 통과했다는 주장은 하지 않는다. P04는 계속 RED/partial이다.

Backend 288e14a788b88e8a319280de02f877dc1573667e와 frontend 93b8c2e1f459e08538e92b94184834c90f0ed322는 authenticated mother의 실제 대여 선택 하위 게이트를 닫았다. Disposable GoTrue/PostgREST/Supabase/FastAPI/Astro same-origin runtime에서 desktop/mobile 열 카드가 각각 revision 11과 final review 200에 도달했다. 산모가 health_cushion_rental을 선택하면 source-owned voucher/rental catalog가 terminal PATCH에서 준비되고, voucher day 10일만 일정 축으로 사용해 occurrence 10개를 만든다. 최종 quote는 장비료 0원, 예약 단위 왕복 배송비 10,000원, customer payable 210,000원이며 charge handoff가 rental catalog/selection SHA-256 두 개를 보존한다. 공개 quote line은 pinned 계약의 여섯 필드만 포함한다. 자동 focus/scroll, 완료 카드 편집과 파생 권위 11개 재투영, actual 422/409/403/401, overflow 및 browser diagnostics 0을 다시 통과했다. 공개 pack p04-live-rental-288e14a7-93b8c2e1은 파일 45개, manifest asset 44개다. Backend full 7,087, frontend 95 files / 592 tests, Ruff/lint/Astro check/build와 Tach diagnostic 0이 통과했다. Legal acceptance, confirmation-ready confirm, 실제 accepted evidence·booking handoff·lineage/replay가 미완이라 P04와 전체 진도 3/13 (23.1%)는 변하지 않는다. Payment·service-balance·report/document·payout· settlement의 실제 소비는 P07/P08/P10/P11-P13이 각각 검증한다.

Backend c27a69843196e04af88daf8011afd256a2a421cd는 P04 DB 검증을 supabase:test:customer-reservation-full-replay로 자동화했다. Pinned PostgreSQL, GoTrue, Storage만 사용하는 disposable network에서 repository migration 314개 전체를 clean replay하고 latest 20260718170000, public-schema lint error 0, exact-26 materializer smoke, resource cleanup을 검증했다. pg-delta catalog-cache warning은 non-fatal이며 reset, lint, smoke 결과를 바꾸지 않았다. 새 actor/Chromium/WebP나 stage/production 배포는 실행하지 않았고 legal/final confirm도 여전히 미완이므로 P04는 RED/partial이다.

Backend 9d8c6e1460e520823a644ef6a8583c4886962df9는 그 clean full-history command에서 data-driven P04 catalog smoke 7개를 연속 실행한다. Voucher population, private-care publication, owner promotion, reviewed-empty regional support, rental equipment, service priority, personality가 모두 transaction rollback으로 residue 없이 통과했고 rental option 5, priority 3, personality question/option 6/12, production publisher 26을 확인한 뒤 exact-26 materializer도 통과했다. 운영 non-empty regional rule을 만들거나 stage/production을 수정하지 않았으므로 P04는 계속 RED/partial이다.

Backend 31ac884512e2fd23294d7b84c9c4dee56ab978bf는 대여용품 명칭·비목·요금 변경을 코드 배포와 분리했다. Pricing Settlement의 domain → application command/port → Supabase adapter → orchestration 순서로 발행 경계를 두고, DB가 catalog/source fingerprint와 행 수를 계산한다. 발행 revision과 supersession은 append-only다. 기존 revision을 update/delete 하지 않으며, exact replay만 허용하고 같은 key의 다른 사실은 거절한다. Full-history 315/315, latest 20260718180000, lint error 0, 기존 날짜 5개/대체 날짜 2개, exact-26와 cleanup이 실제 disposable DB에서 통과했다. Active Supabase user를 publisher로 파생하고 accepted HQ manage authority를 SpiceDB에서 검사하는 POST route가 real main/OpenAPI에 연결됐다. Full Python은 7,062 passed다. 관리자 편집 UI와 실제 HQ actor Chromium/WebP는 아직 없으므로 운영자 화면 완료로 승격하지 않는다.

Backend 4c9dd40fcef076d1e27fb5f053af82ad92f2cbb1와 frontend 3dd5779b4c1133d812786dbc0419c0d29234bd1e는 P04 본사 대여용품 실제 actor 증거를 고정했다. Disposable real GoTrue·SpiceDB·PostgREST·migrated Supabase PostgreSQL과 production FastAPI/Astro composition을 route interception 없이 연결했다. 실제 HQ actor의 current GET, UI revision 편집, immutable POST, 5 → 6 reload, exact replay, altered replay 거절과 DB 무변경, 비권한 actor GET/POST 403, direct SQL revision/supersession/evidence 계보, desktop table·mobile cards·overflow/error 0, actor/relationship/runtime cleanup이 통과했다. 본사 대여용품 관리 하위 게이트는 GREEN이다. 당시에는 실제 산모 선택과 같은 revision의 quote/booking/payment/settlement/document 소비가 미완이었다. 이 중 downstream actual 소비는 현재 기준에서도 P04 gate가 아니라 각 consumer phase 소유다. 아래 7f51408b에서 selection→quote→booking→finalized-charge code gate만 후속 완료됐고, authenticated browser의 legal/final confirm과 persisted booking handoff, production source 승인은 미완이라 P04는 계속 RED/partial이다. 당시 Backend full은 7,067 passed, frontend full은 95 files / 591 tests, Astro 7 check/build PASS다. 온라인 배포는 하지 않았다.

Backend 7f51408b9f5ba81452ec8923307fc43c251eeccf는 대여용품 후속 code gate를 닫았다. Pricing Settlement의 명시적 cross-context contract가 선택 항목·catalog revision· offering·배송비 최대 1회·지점 확인 결과를 동결한다. Final review는 같은 revision으로 rental quote line과 payable 및 charge handoff pricing key를 만들고, accepted handoff translator는 plan/quote/offering/revision drift를 거절한다. Booking command와 Restate workflow input, finalized charge snapshot도 같은 line별 policy version을 보존한다. Unknown/duplicate 선택, 지점 미확인 유축기, 변조된 quote/revision은 테스트에서 거절된다. Focused 153 passed, full 7,079 passed, Ruff/Tach PASS, 새 contract/query Vulture confidence-100 후보 0이다. 새 actor/browser/WebP·실제 accepted legal evidence/booking handoff 실행은 없으므로 P04는 계속 RED/partial이다. 실제 Supabase payment/service/report/settlement 실행은 후속 phase 소유다.