P01 Supabase 내구성 검증 기준

이 페이지는 Actor A-Z 워크플로우 Acceptance SSOT의 P01-branch-onboarding 중 Supabase persistence 하위 gate다. 상위 결정은 ADR-030과 ADR-033이다.

검증 경계

Supabase PostgreSQL이 branch, command, revision, invitation, audit, effect journal의 primary authority다.
Python SQL 문자열 검사, mock RPC, fixture-only adapter 테스트는 실제 원자성 증거가 아니다.
dirty workspace의 미추적 reservation migration은 실행 대상에서 제외한다. runner는 Git이 추적하는 명시적 P01 dependency migration과 P01 migration 하나만 disposable local DB에 replay한다.
custom image build는 없다. 캐시된 Supabase 공식 컨테이너만 실행하고 종료 시 container와 관련 임시 artifact를 제거한다. test DB를 폐기한다.
온라인 배포, stage mutation, screenshot, WebP 수집은 이 gate의 권한 밖이다.

저장 권위

권위	판정	P01 사용 규칙
`sanmopia_branch_profiles`	재사용	UUID branch와 HQ parent를 저장한다.
`sanmopia_branch_office_profiles`	확장 후 재사용	core branch FK, 분리된 business/address facts, revision 1을 저장한다.
`sanmopia_branch_membership_fee_policies`	재사용	초기 회비 정책 revision 1을 저장한다.
`sanmopia_branch_memberships`	P01 초대에 사용 금지	상태 열이 없어 row 존재가 즉시 활성 권한이 된다.
`sanmopia_branch_manager_membership_invitations`	신규	P01의 `invited` membership authority를 실제 membership과 분리한다.
`sanmopia_branch_organization_revision_states`	신규	HQ별 organization revision의 유일한 CAS 권위다.
`sanmopia_branch_onboarding_commands`	신규	actor/HQ/key/command/claim, immutable accepted, mutable current를 저장한다.
`sanmopia_branch_onboarding_side_effect_journal`	신규	정확한 다섯 effect의 최신 durable 상태를 저장한다.
`sanmopia_branch_onboarding_audits`	신규	append-only command/audit lineage를 cleanup 뒤에도 보존한다.
`private.sanmopia_branch_onboarding_accepted_results`	DB12 신규	mutable command와 독립된 append-only accepted-result receipt를 cleanup 뒤에도 보존한다. Data API direct 권한은 없다.

순차 acceptance matrix

순서	Case	실제 DB assertion	상위 case
01	`P01-DB-ACL`	내부 다섯 table은 RLS가 켜지고 직접 table 권한이 없으며 mutation RPC는 `service_role`만 실행한다. 모든 `SECURITY DEFINER` 함수는 빈 `search_path`와 fully-qualified object를 사용한다.	authorization
02	`P01-DB-ATOMIC-START`	start 한 transaction이 core branch, office revision 1, organization revision, command, audit, 정확히 다섯 pending effect를 모두 만들거나 모두 만들지 않는다. pending effect의 invitation, active membership, fee row는 아직 없다.	happy path
03	`P01-DB-INVITATION-ONLY`	manager-membership effect 완료는 별도 invitation row를 `invited`로 만들지만 `sanmopia_branch_memberships`에는 manager row를 만들지 않는다.	happy path, authorization
04	`P01-DB-EXACT-REPLAY`	같은 HQ/key/actor/request는 organization revision이 이미 전진했어도 revision CAS보다 먼저 기존 command를 찾아 같은 branch/snapshot을 반환하고 row를 중복하지 않는다.	exact replay
05	`P01-DB-KEY-MISMATCH`	같은 HQ/key의 actor, request, fingerprint, command, claim 변경은 idempotency mismatch이며 business row 증가가 0이다.	conflict
06	`P01-DB-CLAIM-OWNERSHIP`	같은 `claim_id` 또는 identity namespace를 다른 HQ/key/fingerprint/email/disposition에 재결속할 수 없다.	conflict, cleanup
07	`P01-DB-BUSINESS-CONFLICT`	서로 독립된 fresh command로 stale organization revision은 `22023 branch onboarding organization revision is stale`, duplicate branch code는 `22023 branch onboarding branch code is already owned`, duplicate `(business_jurisdiction, business_registration_number)`는 `22023 branch onboarding business identity is already owned`여야 한다. 세 직렬 거부 모두 기존 두 branch snapshot, 두 HQ revision, 열 가지 authority count를 바꾸지 않고 candidate branch/command를 남기지 않는다. 서로 다른 HQ의 branch-code 경합과 business-identity 경합도 각각 실제 두 backend session에서 winner 1, 같은 exact `22023` loser 1, candidate-scoped loser partial 0이어야 한다.	conflict
08	`P01-DB-EFFECT-CAS`	허용된 effect status/reference/failure 전이와 command state revision은 같은 transaction에서 한 번에 전진하고 반환 snapshot과 일치한다. pre-acceptance 전이는 accepted/current snapshot을 계속 null로 유지한다.	happy path
09	`P01-DB-EFFECT-REJECT`	stale state revision/status/reference, reference rewrite, completed regression, malformed JSON/canonical text, actor/HQ/key/command/branch cross-scope는 모두 exact typed error와 저장 변화 없이 거부된다.	conflict, authorization, exact replay
10	`P01-DB-FINALIZE`	accepted/current는 한 transaction에서 함께 최초 기록되고 accepted는 write-once다. POST replay delivery만 `idempotentReplay=true`가 될 수 있다.	happy path, exact replay
11	`P01-DB-REPAIR`	기존 transition RPC가 repair-pending accepted 이후 journal 한 건, strict current, command revision을 원자적으로 단조 전진시킨다. accepted와 actor/HQ/key/command/branch/claim/request/plan/audit는 불변이며 stale duplicate는 `40001`이다.	happy path, conflict, exact replay, cleanup
12	`P01-DB-CURRENT-SCOPE`	GET RPC는 정확한 actor/HQ/command envelope 하나만 반환하고 저장 current payload는 항상 `idempotentReplay=false`다. cross-scope 조회는 빈 결과다.	authorization, exact replay
13	`P01-DB-CLEANUP`	test-owned command, journal, invitation, fee, office, core branch를 제거해 운영 검색 잔여가 0이고 public audit + private accepted receipt는 정확한 retained evidence pair로 남는다. 전체 SQL fixture transaction도 마지막에 rollback한다.	cleanup

한 case가 RED면 다음 case를 GREEN으로 선언하지 않는다. 실패 case를 테스트로 고정하고 최소 production 변경으로 닫은 뒤, 앞선 모든 case를 다시 실행한다.

DB07 criteria pin

stale revision, duplicate branch code, duplicate business identity는 각각 새 key, command, claim, identity, normalized email, branch UUID를 사용한다. 따라서 DB05 key mismatch와 DB06 identity ownership이 먼저 실패해 DB07을 가리는 fixture는 무효다.
branch code의 최종 권위는 기존 전역 constraint sanmopia_branch_profiles_branch_code_key다. business identity의 최종 권위는 기존 전역 partial unique index sanmopia_branch_office_profiles_business_identity_idx다. 별도 중복 권위를 만들지 않는다. 이 index는 정확히 jurisdiction과 registration number 두 열을 가지며, 두 값이 모두 non-null인 row에만 적용되고 unique/valid/ready 상태여야 한다.
각 거부 뒤 branch, office, office revision, organization revision, command, effect, invitation, membership, fee policy, audit 열 가지 count와 기존 두 command snapshot, 두 HQ revision을 모두 비교한다. candidate branch와 command는 각각 0이어야 한다.
serial fixture의 마지막 rollback은 test harness 위생이며 DB13 cleanup 성공 증거가 아니다. DB08 effect CAS, provider, interface, UI, actual actor, screenshot/WebP도 이 gate의 범위가 아니다.
세 독립 직렬 충돌 외에 서로 다른 HQ/key/claim/identity/email/branch UUID를 가진 두 session의 branch-code 경합과 business-identity 경합을 각각 실행한다. 각 worker는 backend PID와 readiness를 먼저 commit하고 controller barrier 뒤에서 함께 출발해야 한다. controller는 두 run_candidate 내부 ShareLock waiter를 먼저 확인하고 wrapper barrier만 해제한다. 이어 production RPC가 쓰는 동일 branch-code/business-identity advisory lock에서 두 backend PID가 ExclusiveLock waiter로 동시에 대기함을 pg_locks로 확인한 뒤에만 authority lock을 해제한다. stored/result PID가 같은 서로 다른 두 session인지 확인하고 winner 1, exact typed loser 1, candidate-scoped loser partial state 0을 검증한다. 단순 background 실행, wrapper barrier만의 증명, 순차 완료는 동시 경합 증거가 아니다.

DB08 criteria pin

DB03에서 manager membership만 완료한 첫 fresh command를 재사용한다. 시작 상태는 stateRevision=2, manager membership effect 하나만 completed, 나머지 네 effect는 pending, accepted/current snapshot은 모두 null이다. branch/office revision과 HQ organization revision은 이미 고정돼 있어야 한다.
남은 네 effect를 operator_identity_provisioning, authorization_relationship_write, manager_invitation_delivery, membership_fee_policy_publication 순서로 각각 pending → completed한다. 각 completed transition은 expectedReferenceId=null, exact non-empty reference, failureCode=null, currentResultSnapshot=null을 사용한다. identity reference는 stored prepared claim의 identityId와 정확히 같아야 한다.
완료 lineage reference는 순서대로 00000000-0000-0000-0000-000000000721, relationship-write-p01, invitation-delivery-p01, fee-policy-p01로 고정한다.
command state revision은 네 RPC에서 정확히 2 → 3 → 4 → 5 → 6으로 한 번씩만 전진한다. 단계별 completed effect 수는 2 → 3 → 4 → 5, pending 수는 3 → 2 → 1 → 0이어야 한다.
별도 repairable lineage는 아직 untouched인 두 번째 command에서 시작한다. identity effect를 pending → retrying으로 만들 때 reference 없이 identity_provider_unavailable을 기록하고, retrying → retrying에서 stored claim identity reference 00000000-0000-0000-0000-000000000722를 얻은 채 identity_confirmation_timeout을 기록한 뒤, 같은 expected/new reference로 retrying → completed한다. 이어 authorization effect를 relationship-write-p01-2와 authorization_relationship_write_unavailable이 있는 pending → retrying으로 남긴다. revision은 정확히 1 → 2 → 3 → 4 → 5다.
이 두 lineage는 provider-neutral 성공 matrix의 pending → completed, reference 없는 pending → retrying, reference를 얻는 retrying → retrying, reference를 보존하는 retrying → completed, reference 있는 pending → retrying을 모두 실행한다. retrying은 failure가 필수이고 reference는 선택이며, known expected reference가 있으면 새 reference는 정확히 같아야 한다. 완료 lineage는 DB10 completed finalize, repairable lineage는 DB10 repair-pending과 DB11 repair를 위한 입력일 뿐 그 후속 gate의 GREEN 증거는 아니다.
레거시 Branch_model.php:239-261은 branch insert 뒤 auth token과 당월 회비를 만들지만 token은 별도 transaction이고 호출 결과를 쓰지 않으며 fee write 결과도 확인하지 않은 채 성공을 반환한다. office_detail.js:253도 boolean 성공 뒤 redirect/reload만 한다. DB08은 이 순서 자체는 보존하되 provider 결과, failure, reference, resume 가능 revision을 durable journal로 드러내어 레거시의 보이지 않는 partial progress를 개선한다.
각 RPC는 exact actor/HQ/idempotency key/command/branch scope와 expected command revision, expected effect status/reference를 CAS한다. 반환 snapshot의 state revision은 command row와 같고, 반환 snapshot의 대상 effect status/reference/failure는 journal row와 같아야 한다. 다른 네 effect 또는 대상 effect 이외의 journal 사실은 변하지 않는다. pre-acceptance DB08은 accepted/current payload를 만들지 않으며 provider resource를 실제로 생성했다는 증거도 아니다.
각 성공 전이 동안 branch, office, office revision, organization revision, command scope/claim, audit, invitation, active membership, fee policy의 identity와 count는 불변이다. DB08이 허용하는 유일한 business-state 변화는 대상 journal 사실, command state_revision, 두 row의 updated_at이다.
stale state revision/status, expected reference mismatch, reference rewrite, completed regression, malformed payload와 cross-scope 무변경은 DB09가 소유한다. accepted/current 최초 동시 기록은 DB10, accepted 이후 current/effect repair는 DB11, scoped GET은 DB12, audit-preserving cleanup은 DB13이다. DB08 gate가 이 후속 gate를 미리 GREEN으로 만들 수 없다.

DB09 criteria pin

DB08 종료 fixture를 그대로 사용한다. completed lineage는 command revision 6과 effect completed=5, repairable lineage는 revision 5와 identity completed, authorization retrying(referenceId=relationship-write-p01-2), 나머지 세 effect pending이다. 두 command의 accepted/current는 계속 null이다. DB09는 새 command나 provider resource를 만들지 않는다.
stale command revision은 exact 40001 / branch onboarding durable state changed concurrently, stale effect status와 expected-reference mismatch는 exact 40001 / branch onboarding durable effect changed concurrently여야 한다. reference rewrite와 explicit completed regression은 exact 22023 / branch onboarding transition payload is invalid여야 한다. completed effect를 retrying이라고 위조한 CAS도 durable-effect 40001이어야 한다.
null/array envelope, missing/extra key는 exact 22023 / branch onboarding transition input is invalid이다. 여섯 payload field는 enum/status 세 개는 JSON string, expected/reference/failure 세 개는 JSON string 또는 null이어야 한다. number, boolean, object, array를 ->>로 문자열화해 받지 않는다. 여섯 field 각각에 네 non-string type을 대입한 6 x 4 = 24 case를 실행한다. expectedReferenceId case는 같은 exception subtransaction 안에서 stored effect reference와 canonical referenceId를 문자열화 결과에 맞추는 test-only fixture를 사용해, reference validator나 CAS가 아니라 expected-reference의 실제 JSON type 검증 누락만으로 성공하게 만든다. fixture와 성공 mutation은 모두 case 종료 전에 rollback한다.
string type이어도 unknown effect kind/status, newStatus=pending, pending effect의 non-null expected reference, reference 없는 completed, failure가 있는 completed, failure 없는 retrying은 모두 exact 22023 / branch onboarding transition payload is invalid이다. 각 semantic contradiction도 다른 case와 같은 전체 row/timestamp 불변을 검증한다.
operator-identity effect의 non-null referenceId가 stored prepared claim의 identityId와 다르면 exact 22023 / branch onboarding operator identity reference is invalid이고 전체 row/timestamp는 불변이다.
application _require_canonical_text의 strip() 경계와 맞춰 expected/reference/failure의 앞뒤 Python 3.13 str.isspace() 29 code point를 3 field x 29 whitespace x 2 edge = 174 case로 exact payload 22023 거부한다. 집합은 U+0009..000D, U+001C..001F, U+0020, U+0085, U+00A0, U+1680, U+2000..200A, U+2028, U+2029, U+202F, U+205F, U+3000이며 SQL matrix에 code point를 명시한다. DB08 감사에서 찾은 non-string reference/failure/expected-reference와 tab/newline, DB09 production 감사의 NBSP 반례가 이 gate의 필수 입력이다.
같은 strip() 경계를 execution scope에도 적용한다. actor, HQ, idempotency key, command, branch 각각에 앞뒤 29 code point를 넣은 5 field x 29 whitespace x 2 edge = 290 case는 exact 22023 / branch onboarding transition input is invalid이고 전체 row/timestamp가 불변이어야 한다. UUID cast나 raw no-row 오류까지 진행시키지 않는다.
actor, HQ, idempotency key, command, branch를 각각 하나씩 다른 canonical 값으로 바꾼 다섯 cross-scope 호출은 모두 exact 22023 / branch onboarding transition scope mismatch여야 한다. raw P0002 query returned no rows를 내부 계약으로 노출하지 않는다.
각 case는 호출 직전의 두 private snapshot, 모든 raw command/effect row, branch, office, office revision, HQ organization revision, invitation, active membership, fee policy, audit 전체 row와 count를 캡처한다. 거부 뒤 timestamp까지 exact 동일하고 receipt는 없어야 한다. 성공 sentinel도 exception subtransaction에서 rollback한 뒤 RED로 다시 올려 다음 case를 오염시키지 않는다.
레거시 실제 진입은 OfficeManagement.php:399-449 → Branch_model.php:202-259이다. controller는 login ID를 선조회하지만 expected revision/lock/idempotency key가 없고, model은 branch 저장 뒤 User_model.php:23-39의 별도 token transaction과 Branch_model.php:261-287의 당월 fee check-then-write를 호출한다. token/fee 결과를 사용하지 않고 항상 true를 반환하며, JS office_detail.js:253-285는 boolean 성공 뒤 redirect/reload한다. DB09의 typed conflict와 exact no-change는 이 보이지 않는 partial progress를 막는 개선이다.
레거시 P01 경로에는 manager invitation이나 delivery 호출이 없다. invitation-only membership과 delivery journal은 명시적 현대화 결정이며 레거시 기능이라고 주장하지 않는다. DB09는 잘못된 effect 전이만 거부한다. 최초 accepted/current 기록은 DB10, post-acceptance repair는 DB11, scoped GET은 DB12, cleanup은 DB13이므로 이 gate에서 열지 않는다.

DB10 criteria pin

레거시 OfficeManagement.php:399-449 → Branch_model.php:202-287의 status:true는 token과 당월 fee 결과를 확인하지 않은 boolean이다. idempotency, revision CAS, accepted/current snapshot, response-loss replay도 없다. DB10의 atomic finalize와 write-once accepted는 레거시 복제가 아니라 partial success와 중복 재시도를 막는 명시적 개선이다.
DB10 public persistence contract는 sanmopia_finalize_branch_onboarding_accepted_and_current(text,text,text,text,text,integer,jsonb) 하나다. exact actor/HQ/idempotency key/command/branch scope, expected command revision, strict result payload를 받으며 accepted payload와 delivery-only idempotent_replay를 반환한다. SECURITY DEFINER, 빈 search_path, service-role-only execute가 필수다.
result shape의 불변 기준은 contract 918d797c578df43edc6697a85ab3016409bb75ee의 schemas/branch-operations/branch_onboarding_result.schema.json과 그 revision에서 생성된 binding이다. top-level은 additionalProperties:false인 아래 25개 key를 정확히 한 번씩 가져야 한다.
```
commandId, actorId, reason, commandFingerprint, branchId, branchCode,
revision, organizationRevision, lifecycleStatus, operatorIdentityId,
operatorIdentityDisposition, managerMembershipId, managerMembershipStatus,
managerInvitationStatus, authorizationRelationshipStatus,
authorizationRelationships, membershipFeePolicyId,
membershipFeePolicyRevision, membershipFeePolicyStatus, sideEffects,
auditEventId, outcomeStatus, idempotentReplay, repair, allowedNextActions
```
revision은 integer 1, organizationRevision은 양의 integer, idempotentReplay는 boolean false다. ID/reason/fingerprint/code/audit와 status는 schema의 string pattern/enum을 그대로 지키며 nullable identity/membership/fee field만 JSON null을 허용한다. authorizationRelationships는 canonical 세 종류를 각각 한 번, sideEffects는 다섯 kind를 각각 한 번, allowedNextActions는 outcome별 exact set을 가진 JSON array다. 각 side effect는 additionalProperties:false인 kind/status/referenceId/failureCode 네 key와 schema raw type을, repair는 null 또는 additionalProperties:false인 repairId/nextRetryAt 두 key와 millisecond UTC timestamp/null을 가진다.
completed lineage는 hq-admin-p01 / HQ 00000000-0000-0000-0000-000000000701 / p01-key-1 / branch-command-p01 / branch 00000000-0000-0000-0000-000000000711, pre-finalize revision 6을 사용한다. 결과의 command/actor/reason/fingerprint는 branch-command-p01 / hq-admin-p01 / 신규 강남 지점 개설 / a×64, plan facts는 branch code B-P01, result revision 1, organization revision 8, lifecycle onboarding이다. identity는 00000000-0000-0000-0000-000000000721 / created, manager membership은 00000000-0000-0000-0000-000000000731 / invited, invitation은 sent, authorization은 active와 canonical 세 relationship, fee는 fee-policy-p01 / 1 / published다. 다섯 effect는 모두 completed/failureCode:null이고 reference가 순서와 무관하게 각각 identity ID, membership ID, relationship-write-p01, invitation-delivery-p01, fee-policy-p01이다. audit ID는 같은 command의 단일 durable audit row에서 읽는다. outcome은 completed, repair는 null, actions는 exact set {complete_branch_profile, configure_service_area, resend_manager_invitation}다. 이 payload를 저장하고 command revision만 6 → 7로 전진시킨다.
repairable lineage는 hq-admin-p01-2 / HQ 00000000-0000-0000-0000-000000000702 / p01-key-2 / branch-command-p01 / branch 00000000-0000-0000-0000-000000000712, pre-finalize revision 5를 사용한다. command/actor/reason/fingerprint는 branch-command-p01 / hq-admin-p01-2 / 신규 송파 지점 개설 / b×64, plan facts는 branch code B-P01-2, result revision 1, organization revision 1, lifecycle onboarding이다. identity는 00000000-0000-0000-0000-000000000722 / created; manager membership ID/status는 null이고 invitation은 pending; authorization은 retrying과 canonical 세 relationship; fee ID/revision은 null이고 status는 pending이다. identity effect만 completed/reference identity ID, authorization effect만 retrying / relationship-write-p01-2 / authorization_relationship_write_unavailable, 나머지 세 effect는 pending / null / null이다. audit ID는 같은 command의 단일 durable audit row에서 읽는다. outcome은 repair_pending, repair fixture A는 {repairId:"repair-p01-2",nextRetryAt:"2026-07-15T03:04:05.123Z"}, actions는 exact singleton [inspect_onboarding_repair]다. repair ID/time은 DB09 authority에서 파생됐다고 주장하지 않고 DB10 result 입력 fixture가 명시적으로 소유한다. 이 payload를 저장하고 revision을 5 → 6으로 전진시키되 effect를 완료하지 않는다.
최초 finalize는 같은 transaction의 한 command update로 accepted/current를 동일 payload로 함께 기록한다. 세 set-semantics array는 입력 순서와 무관하게 관계 parent_hq → hq_admin → branch_operator, effect operator_identity_provisioning → manager_membership_creation → authorization_relationship_write → manager_invitation_delivery → membership_fee_policy_publication, action은 public enum 선언 순서로 normalize한 canonical payload만 비교·저장한다. 이 순서는 storage canonicalization이지 caller가 맞춰야 하는 public precondition이 아니다. 저장 payload의 raw idempotentReplay는 boolean false이고 반환 replay도 false다. 허용 변화는 대상 command의 state_revision, 두 result payload, updated_at뿐이다. journal, branch/office/revision, invitation/membership/fee/audit, 다른 command는 exact 불변이다.
이미 accepted인 exact payload는 expected revision CAS보다 먼저 immutable accepted와 비교해 stored accepted를 반환하고 delivery replay만 true로 만든다. command timestamp를 포함한 전체 저장 상태는 불변이다. 다른 payload는 exact 22023 branch onboarding accepted result is immutable로 거부한다. 여기서 exact는 세 array를 위 canonical form으로 만든 뒤의 semantic equality다. 관계, effect, action 배열 각각과 세 배열 동시의 order-only permutation은 original expected revision으로 replay true이고 stored canonical payload/timestamp가 불변인 executable case를 가진다. 따라서 response loss 뒤 원래 pre-finalize revision으로 재호출해도 중복 finalize하지 않는다.
pre-acceptance stale revision은 exact 40001 branch onboarding durable state changed concurrently, 다섯 canonical scope mismatch는 exact 22023 branch onboarding finalize scope mismatch다. executable shape matrix는 위 immutable schema에서 생성한다. 25개 top-level key 각각의 missing, top-level extra key, 각 key에 대해 허용되지 않은 JSON raw kind(null/boolean/number/string/array/object), idempotentReplay=true, array cardinality/duplicate/unknown enum을 모두 개별 case로 둔다. 다섯 side-effect object 각각에는 네 key 각각의 missing, extra key, 각 key의 invalid raw kind와 status/reference/failure 모순을 적용하고, repair object에는 두 key 각각의 missing, extra key, invalid raw kind와 timestamp format 오류를 적용한다. 입력 자체의 null/scalar/array도 포함한다. 같은 JSON kind 안의 value 제약도 별도 case다. 모든 non-null string의 empty/whitespace-only, commandId 200자 초과, reason 500자 초과, fingerprint의 길이/대문자/non-hex, branch code의 첫 문자/허용 문자/32자 제한, 각 ID/reference/failure/repair ID의 non-whitespace, 모든 enum의 unknown, revision != 1, organizationRevision < 1, non-null fee revision != 1, canonical millisecond UTC가 아닌 retry time을 포함한다. schema-level value 오류를 durable mismatch로 뒤늦게 분류하면 실패다. 모든 case는 exact 22023 branch onboarding finalize input is invalid와 whole-state/timestamp 불변을 증명한다.
RPC scalar envelope도 result JSON보다 먼저 닫는다. actor/HQ/key/command/branch 각각의 SQL null, empty, Python 3.13 str.isspace()와 같은 29 code point별 whitespace-only 및 leading/trailing text, idempotency key 255자 초과, command ID 200자 초과, HQ/branch의 invalid UUID와 non-canonical UUID spelling, expected revision의 SQL null/0/음수를 table-driven case로 실행한다. 이 malformed envelope는 raw cast/no-row를 노출하지 않고 exact 22023 branch onboarding finalize input is invalid와 whole-state/timestamp 불변이어야 한다. 오직 canonical하고 well-formed지만 다른 다섯 scope 값만 finalize scope mismatch로 분류한다.
shape가 맞아도 actor/command/branch/reason/fingerprint, plan의 branch/revision/organization/lifecycle, audit event, prepared identity claim, 다섯 effect status/reference/failure, resource aggregate, outcome/repair-nullability/allowed-actions가 durable facts와 다르면 exact 22023 branch onboarding final result does not match durable state다. P02가 소유하는 active manager membership 또는 accepted invitation도 같은 오류로 닫는다. effect와 completed actions는 집합 의미를 검증하고 불필요한 배열 순서를 새 계약으로 만들지 않는다. non-null repair의 ID/time은 DB09 durable parity 비교 대상이 아니며 위 public shape와 repair-pending 결속을 통과한 coordinator-owned input이다. 최초 accepted 뒤에만 exact immutable fact가 된다.
동시 exact finalize 두 호출은 첫 delivery false 하나와 replay true 하나, revision 증가 한 번, partial state 0이어야 한다. 서로 다른 valid payload race는 동일한 repairable durable facts에 fixture A와 repair만 {repairId:"repair-p01-2-alt",nextRetryAt:"2026-07-15T03:04:06.123Z"}인 fixture B를 동시에 제출한다. repair envelope는 DB09 table에서 파생되는 authority가 아니라 coordinator-owned finalize 입력이며 DB10은 public shape/outcome만 검증하고 최초 writer가 accepted fact로 동결한다. 따라서 A/B는 모두 pre-finalize에는 valid지만 accepted payload로는 다르며, accepted winner 하나와 exact immutable loser 하나뿐이고 loser가 accepted/current를 덮지 못해야 한다.
두 race는 smoke transaction의 마지막 rollback에 기대지 않는다. committed setup은 public start/transition RPC를 통해 다음 고유 lineage를 DB10 직전 revision까지 만든 뒤 commit한다. same-payload completed race는 hq-admin-p01-db10-same / HQ 00000000-0000-0000-0000-000000001001 / p01-db10-same-key / branch-command-p01-db10-same / branch 00000000-0000-0000-0000-000000001011 / identity 00000000-0000-0000-0000-000000001021 / membership 00000000-0000-0000-0000-000000001031 / revision 6이다. different-payload repair race는 hq-admin-p01-db10-different / HQ 00000000-0000-0000-0000-000000001002 / p01-db10-different-key / branch-command-p01-db10-different / branch 00000000-0000-0000-0000-000000001012 / identity 00000000-0000-0000-0000-000000001022 / revision 5다.
controller는 transaction의 target command row lock을 잡고 두 worker가 실제 target lock waiter인 것을 backend PID/lock graph로 확인한 뒤 release한다. worker readiness는 별도 transaction으로 먼저 commit한다. 결과는 same-payload의 first=1/replay=1/revision-increment=1/partial=0, different-payload의 winner=1/immutable-loser=1/revision-increment=1/partial=0, accepted/current exact winner snapshot, 예상 외 row/timestamp 변화 없음이다. append-only audit의 update/delete 차단 trigger를 우회하지 않는다. harness는 fresh migration을 마친 source postgres의 authority counts를 기록하고 전용 disposable sanmopia_p01_db10_race database를 clone해 그 안에서만 fixture/race를 실행한다. always-run trap은 helper schema와 clone database를 제거하고 database 부재 및 source postgres baseline counts exact를 확인한다. 최종 container teardown은 이 방어선의 바깥 cleanup이다. 재사용/외부 DB에서는 race를 실행하지 않는다.
DB10 첫 executable RED는 DB01-09를 모두 통과한 뒤 exact P01-DB-FINALIZE missing finalize RPC여야 한다. RPC 부재를 먼저 to_regprocedure로 확인하고 호출은 dynamic SQL로 두어 parser 오류가 product RED를 가리지 않게 한다. DB09 본문은 byte-identical로 보존하고 DB11 current repair, DB12 scoped GET, DB13 cleanup, provider/HTTP/UI/ actual actor 증거는 열지 않는다.

DB01–DB13 누적 실행 절차와 RED/GREEN 기록 펼치기

실행 절차

Criteria pin

현재 DB case의 이 페이지, actor workflow YAML, ADR revision을 먼저 커밋한다.
RED pin

기존 GREEN body를 byte-identical로 유지하고 현재 case SQL/race만 append한다. production 변경 없이 fresh runner에서 이전 case를 모두 통과한 뒤 현재 case의 exact product sentinel 하나를 증명하고 test revision을 커밋한다.
Current case GREEN

그 RED만 닫는 최소 production 변경을 한다. 다음 DB case, provider, interface, UI는 열지 않는다.
Regression gate

fresh DB01부터 현재 case, 현재 case가 소유한 serial matrix와 race, fixture rollback/teardown, public lint와 scoped Python/Ruff/Tach/Vulture를 같은 revision에서 통과시킨다.
Evidence then next criteria

GREEN revision, exact 명령/결과, 독립 감사와 남은 RED 경계를 문서에 커밋한 뒤에만 다음 case criteria를 연다. 현재 순서는 DB11 repair이며 DB12 scoped GET과 DB13 cleanup은 각각 이후의 별도 RED→GREEN gate다.

예정된 실제 DB gate 명령은 다음 하나다.

pnpm run -s supabase:test:local-branch-onboarding-durable-store

최초 RED 기록

기준 문서 revision: assembly 5bc1cbcd7cd9e7f7fc78d020d49e8ed572fbd9c4.
실행 test revision: backend ffffad87429f6021bd0d77cafa56144f8a3e97ef.
실제 첫 product RED: P01-DB-ACL missing authority table public.sanmopia_branch_organization_revision_states.
격리 baseline은 core access control, settlement statement persistence, branch settlement participation, branch office profile runtime 네 tracked migration이다. P01이 재사용하는 branch, membership, office, fee table을 변경하거나 office migration이 직접 참조하는 lineage만 포함한다.
PostgreSQL과 Storage schema는 캐시된 공식 Supabase image digest로 bootstrap했다. custom image build와 image download는 없었다.
이 LXC의 Docker AppArmor 기본 profile이 PostgreSQL Unix socket을 막아 disposable DB container 하나에만 apparmor=unconfined를 적용했다. 전체 daemon이나 workspace 권한은 바꾸지 않았다.
전체 tracked replay를 진단했을 때 P01과 무관한 20260711214612_payment_change_capability_split.sql의 historical source drift가 별도로 발견됐다. 이 결함은 P01 RED로 세지 않으며 platform migration-replay gap으로 남긴다.
이 절의 최초 RED 기록은 당시 historical DB01 baseline이다. 현재 executable SQL은 DB01-11과 누적 3,719-case serial matrix까지 GREEN이며 DB12 scoped GET이 다음 RED다. DB12-13은 각각 production 변경 전에 별도 criteria와 executable RED를 같은 smoke에 append한다.

DB01-02 GREEN 기록

production revision: backend b9e617bed95243073d1b32bb640be6f6f43dd33c.
pnpm run -s supabase:test:local-branch-onboarding-durable-store가 명시적 네 dependency와 P01 migration만 fresh replay하고 Supabase db lint --level error의 0 result, SQL smoke, fixture rollback, disposable container cleanup을 모두 통과했다.
DB01은 내부 다섯 table의 RLS와 direct table privilege 부재, 두 public RPC의 service_role 전용 execute, 실제 pg_proc의 SECURITY DEFINER와 빈 search_path를 catalog에서 검증한다.
DB02는 root HQ revision의 원자적 0 초기화, canonical HQ UUID advisory lock, HQ별 같은 command ID 허용, organization revision 7 -> 8, office revision 1, command, append-only audit, 정확히 다섯 pending effect를 검증한다. start 시 invitation, active membership, membership fee row는 아직 없어야 한다.
동일 HQ의 중복 command constraint를 command insert에서 의도적으로 발생시키고, 그 전에 실행된 core branch, office, office revision이 모두 rollback되며 command/effect/audit count와 organization revision이 변하지 않음을 constraint 이름까지 확인했다.
P01 colocated domain/application/adapter regression은 같은 backend state에서 207 passed다. 두 독립 읽기 전용 재감사도 DB01-02 blocker 0으로 판정했다.

DB03 RED 기록

test revision: backend d93f7f1b183228ac3e0db599e696c5ea39212c24.
실제 fresh Supabase의 첫 기대 실패는 P01-DB-INVITATION-ONLY missing side-effect transition RPC다. migration parse나 fixture 문제가 아니라 production transition RPC 부재에서 실패한다.
고정된 success assertion은 manager-membership effect의 pending -> completed, state revision 1 -> 2, stored command에서 파생한 invitation row 하나, active membership 0, 다른 네 effect pending, accepted/current null이다.
두 번째 HQ가 같은 invitation reference를 쓰면 invitation PK 충돌 뒤 command revision과 journal이 원래 pending 상태로 남고 invitation이 생기지 않아야 한다. 이 rollback assertion도 같은 RED에 포함했다.
stale revision/status, reference rewrite, 일반 current-result CAS는 DB08 이후 범위다. DB03 테스트는 그 gate를 미리 GREEN으로 주장하지 않는다.

DB03-04 GREEN 기록

production revision: backend f558b542c39ba8556991cbd8cd19cb4e68d48f1e.
service-role-only transition RPC가 exact actor/HQ/key/command/branch scope와 state revision을 잠그고 manager-membership effect만 pending -> completed로 전이한다. journal과 command revision을 먼저 갱신한 뒤 stored command의 branch, identity, normalized email, display name으로 invited row를 넣으므로 invitation PK 충돌은 선행 write까지 모두 rollback한다.
SQL three-valued logic 반례인 expectedStatus: null과 braced/noncanonical HQ UUID를 production 전 독립 감사가 발견했다. required non-null validation, IS DISTINCT FROM, UUID round-trip canonical check를 추가했고 두 반례가 invitation이나 durable state를 바꾸지 않음을 실제 DB에서 검증했다.
transition 뒤 같은 start request를 replay하면 organization revision CAS보다 먼저 기존 command를 찾아 state revision 2의 최신 snapshot을 resumed로 반환하며 branch, office, command, journal, invitation, audit count가 변하지 않는다. 따라서 DB03이 닫힌 뒤 DB04도 순서상 GREEN이다.
fresh Supabase migration replay, db lint error 0, SQL fixture rollback, P01 colocated domain/application/adapter 207 passed, 두 독립 읽기 전용 재감사를 통과했다.
다른 effect kind와 non-null current payload는 write 전에 0A000으로 닫혀 있다. stale/general transition CAS와 repair는 DB08 이후 RED다.

DB05 RED 기록

test revision: backend 97562ffea2e83308cb1e6a36097cb72ad433c5c8.
같은 HQ/key에서 actor, request, fingerprint, command, claim을 각각 하나씩 바꾼 유효한 다섯 요청과 claim identityId 누락 반례를 실행한다. 모든 case는 정확히 branch onboarding idempotency scope mismatch여야 하며 branch, office, office revision, organization revision, command, effect, invitation, membership, fee policy, audit 열 가지 count가 전후 동일해야 한다.
production 변경 전 fresh Supabase에서 앞의 다섯 유효 변조는 기대대로 거부됐지만 claim-missing-identity는 기존 snapshot을 재생했다. nullable UUID와 <>의 SQL three-valued comparison이 mismatch 조건을 NULL로 만들어 우회한 것이 첫 RED다.
production migration은 이 RED를 기록한 시점에 변경하지 않았다. 누락 identity도 입력 오류가 아니라 기존 key의 scope mismatch로 분류하고, 전체 business row 무변경을 증명하기 전에는 DB05를 GREEN으로 승격하지 않는다.

DB05 GREEN 기록

독립 감사의 추가 반례를 고정한 test revision은 backend e3dc427946eee398bac673c00dcd3db8848278bc, production revision은 backend a172a8628159fd24b1e6e25522cbdc49dc666849이다.
강화 RED는 claim 내부 HQ/key/fingerprint 누락이 replay되는 두 번째 SQL-null 우회를 먼저 확인했다. 이후 actor, request, fingerprint, command, claim 변경, claim identity/HQ/key/fingerprint 누락, braced identity/HQ UUID를 모두 정확한 idempotency-scope mismatch로 닫았다.
existing-key 비교는 stored command facts와 raw claim binding을 IS DISTINCT FROM으로 묶는다. canonical UUID 문자열도 함께 비교하므로 같은 UUID의 다른 표기가 scope를 우회하지 못한다. fresh key의 missing identity는 첫 business write 전에 start input is invalid로 거부된다.
각 mismatch 뒤 열 가지 business-row count뿐 아니라 target revision-two snapshot과 HQ organization revision 8도 그대로임을 검증한다. 따라서 row 증가뿐 아니라 in-place mutation도 실패한다. fresh missing identity도 row count, HQ revision, test branch 부재를 확인한다.
fresh Supabase migration replay, db lint error 0, SQL fixture rollback, container cleanup, P01 colocated domain/application/adapter 207 passed를 통과했다. 두 독립 읽기 전용 감사 모두 DB05 blocker 0으로 판정했다. 이 DB05 GREEN 시점에는 DB06 이후가 RED였다.

DB06 RED 기록

test revision: backend 4a66363d12d844d17a8cb51f3c0ca6c14c390beb.
identity namespace는 prepared claim의 두 alias인 operator_identity_id와 normalized_manager_email을 각각 전역 freeze한다. 두 값을 묶은 composite unique는 identity만 바꾸거나 email만 바꾸는 재결속을 허용하므로 acceptance가 아니다.
actual DB matrix는 same claim/same HQ, same claim/other HQ, new claim/same identity, new claim/same email 네 요청을 새 key, branch, business fact로 실행한다. DB05 existing-key와 DB07 business conflict를 타지 않으며 exact claim 또는 namespace ownership conflict를 요구한다.
각 거부 뒤 열 가지 count, 두 HQ revision, 두 original owner snapshot, candidate branch/command 부재를 확인한다. named individual unique constraint와 fixed-order claim → identity → email lock도 race backstop으로 요구한다.
production 변경 전 fresh Supabase에서 same-claim 두 요청은 거부됐지만 identity-rebind가 started를 반환했다. 현재 command table이 claim_id만 unique이고 identity와 email namespace는 비고유인 것이 첫 RED다. 서로 다른 HQ/key/claim의 동시 race도 GREEN 전에 한 winner와 exact-conflict loser, partial row 0으로 실행 증명해야 한다.

DB06 GREEN 기록

직렬 RED는 backend 4a66363d12d844d17a8cb51f3c0ca6c14c390beb, production은 f0c60e9878b82bc21d6203c3f63f2a4a71e393ad이다. 실제 경합 harness는 backend 51573cfecfa612877ece205d5c93a5f5128018ba, readiness 장벽 hardening은 418678accf1cc7aa995c9f22d87e902253aa0e5f, production RPC authority-lock waiter까지의 최종 hardening은 db2a9058edcdd51487f93554fc92bcbda281d04f에 고정했다.
command authority는 operator_identity_id와 normalized_manager_email에 각각 이름 있는 전역 unique constraint를 둔다. 신규 요청은 HQ/key replay 판정과 canonical claim 검증 뒤 claim → identity → normalized email advisory lock을 고정 순서로 얻고, 첫 business write 전에 exact claim conflict 또는 namespace conflict를 22023으로 반환한다.
직렬 네 case는 same claim의 same/other HQ를 branch onboarding identity claim is already owned로, new claim의 same identity/email을 branch onboarding identity namespace is already owned로 거부한다. 각 거부 뒤 열 가지 count, 두 기존 owner snapshot, 두 HQ revision, candidate branch/command 부재가 유지된다.
identity 경합과 email 경합은 각각 서로 다른 HQ/key/claim/branch/business fact를 가진 두 PostgreSQL backend session으로 실행한다. 각 worker가 readiness와 backend PID를 먼저 commit하고 controller의 wrapper barrier에 막힌다. runner는 두 in-call ShareLock waiter를 확인한 뒤 wrapper만 풀고, production RPC의 동일 identity/email authority lock에서 두 ExclusiveLock waiter를 다시 확인한 뒤 authority를 푼다. stored PID와 결과 PID가 같은지도 검증한다. 두 경합 모두 winner 1, exact 22023 loser 1이다.
candidate 범위에서 branch, office, office revision, command, exact binding, audit은 각각 1, effect는 5, invitation/membership/fee policy는 각각 0, 두 HQ 중 organization revision 1은 하나뿐이다. 이는 loser partial state가 0이라는 뜻이며 전체 DB row가 0이라는 주장이 아니다.
fresh migration replay, Supabase db lint error 0, 직렬 fixture rollback, P01 colocated domain/application/adapter 207 passed, Ruff, Tach internal/external gate를 통과했다. Vulture confidence 100의 세 후보는 실제 Protocol method parameter라 삭제하지 않았다.
race winner와 append-only audit은 assertion 동안 유지하고 helper schema만 drop했다. 이후 disposable DB container를 제거하고 docker inspect 부재를 검증했다. race fixture 자체를 rollback하거나 audit row를 직접 삭제했다고 주장하지 않는다. 장벽 전 적대적 감사가 잡은 false-GREEN 가능성을 hardening한 뒤 재감사는 blocker/high/medium 0이다. DB07 이후와 P01 전체는 계속 RED다.

DB07 RED 기록

기준 revision은 assembly 361de79e536e70d7e7b688ffe2bcfa2c2e44d9b9, 실행 test revision은 backend b87e526a7c34828f179c1f48b3182b526d5bbfe5다. production migration은 이 RED에서 변경하지 않았다.
세 case는 각각 fresh key, command, claim, identity, normalized email, branch UUID를 사용한다. stale organization revision은 HQ1, duplicate branch code와 duplicate business identity는 HQ2의 현재 revision을 기준으로 격리했다. DB05나 DB06이 먼저 실패하는 fixture는 아니다.
catalog assertion은 branch code의 sanmopia_branch_profiles_branch_code_key와 business identity의 sanmopia_branch_office_profiles_business_identity_idx가 실제 unique authority인지 확인한다.
각 conflict 뒤 열 가지 authority count, 두 stored onboarding snapshot, 두 실제 branch/office/ office-revision snapshot, 두 HQ revision, candidate branch/command 부재를 비교한다.
첫 실행에서 test-only catalog array가 name[] = text[]로 비교된 fixture 결함을 발견해 명시적 text cast로 고쳤다. 이 실패는 product RED로 세지 않는다.
수정 후 fresh Supabase replay와 db lint error 0을 지나 stale revision은 exact 22023 branch onboarding organization revision is stale로 통과했다. 다음 duplicate branch code가 raw 23505, message duplicate key value violates unique constraint "sanmopia_branch_profiles_branch_code_key"를 반환한 것이 첫 유효 product RED다. 앞선 순차 실패로 duplicate business identity case는 아직 실행 GREEN 증거가 없다.
runner trap이 disposable sanmopia-p01-supabase-db를 제거했고 docker inspect 부재를 확인했다. DB07 production과 DB08 이후는 계속 RED다.
직렬 RED 뒤 독립 적대감사가 단순 SELECT precheck만으로도 직렬 suite가 거짓 GREEN이 될 수 있음을 확인했다. 다른 HQ의 동시 동일 branch code/business identity는 unique backstop에서 raw 23505 loser가 될 수 있으므로, production 변경 전에 위 두 readiness-barrier race를 별도 RED로 고정해야 한다. 이 보강은 DB07의 실제 typed-conflict 보장이고 DB06 race의 재주장이 아니다.
race 기준 revision은 assembly 8476fea9253d18522867e041895afa472ebb577c, 실행 revision은 backend 6eb6d5e17d32a99acdbdb6240b01a60d5c59ed94다. full gate와 같은 fresh migration/lint를 사용하는 P01_DURABLE_ACCEPTANCE_SCOPE=db07-business-conflict-race scope로 production 변경 없이 경합만 격리 실행했다.
branch-code worker 두 개가 readiness를 먼저 commit했고 controller가 ready=2를 확인한 뒤 barrier를 풀었다. stored/result backend PID는 서로 다른 두 session으로 일치했다. 실제 결과는 winner 1, raw 23505 loser 1이며 loser message와 constraint는 sanmopia_branch_profiles_branch_code_key였다. exact 22023 loser가 아니므로 유효한 race RED다.
순차 race gate는 첫 branch-code failure에서 중단했으므로 business-identity race는 아직 GREEN 증거가 없다. trap 뒤 disposable DB/container 부재를 확인했다. production과 DB08은 계속 RED다.

DB07 GREEN 기록

최종 동시경합 증명은 backend db2a9058edcdd51487f93554fc92bcbda281d04f, production은 e540107db0c1cb75244f91b68b836d1b60d5a3c3이다. production은 새 table/index/constraint를 만들지 않고 기존 branch-code constraint와 business-identity partial unique index를 그대로 최종 권위로 사용한다.
신규 command는 기존 HQ/key replay 판정과 claim/identity/email ownership 검증 뒤 claim → identity → normalized email → branch code → business identity 순서로 advisory lock을 얻는다. organization revision stale 판정을 duplicate business authority보다 먼저 유지하며, 그 다음 branch code와 business identity ownership을 첫 branch write 전에 각각 exact 22023으로 거부한다.
직렬 stale revision, duplicate branch code, duplicate business identity 세 case가 모두 exact message를 반환했다. 각 거부 뒤 기존 두 onboarding command snapshot, 두 실제 branch/office/ office-revision snapshot, 두 HQ revision, 열 가지 authority count가 불변이고 candidate branch/command는 0이다.
precheck 뒤 경합 backstop은 branch와 office insert를 같은 exception subtransaction에 묶고, sanmopia_branch_profiles_branch_code_key와 sanmopia_branch_office_profiles_business_identity_idx에서 온 23505만 각각 exact 22023으로 바꾼다. 알 수 없는 unique constraint는 bare re-raise하므로 unrelated defect를 business conflict로 위장하지 않는다. office unique loser가 먼저 삽입한 branch row도 subtransaction과 함께 rollback된다.
branch-code와 business-identity 경합은 각각 두 distinct backend session으로 실행했다. controller가 두 run_candidate 내부 waiter를 확인한 뒤 wrapper barrier를 풀고, production RPC가 쓰는 정확한 authority advisory lock에서 두 ungranted ExclusiveLock waiter를 다시 확인한 뒤에만 authority를 풀었다. 두 경합 출력은 모두 barrier=ready2 in-call-waiters=2 authority-waiters=2 sessions=2 winner=1 exact-loser=1 partial=0이다.
candidate 범위에서 branch, office, office revision, command, exact binding, audit은 각각 1, effect는 5, invitation/membership/fee policy는 각각 0, organization revision 1은 한 HQ에만 존재한다. loser가 command나 부분 branch를 남기지 않았다는 뜻이며 전체 DB가 비었다는 주장은 아니다.
targeted DB07 scope와 full scope 모두 fresh migration replay, Supabase db lint error 0, 직렬 fixture rollback, 네 경합, helper schema drop, disposable container 부재를 통과했다. P01 colocated domain/application/adapter는 207 passed, Ruff와 Tach internal/external은 통과했다. Vulture confidence 100 세 건은 Protocol port parameter로 확인해 삭제하지 않았다.
최종 harness와 production SQL의 독립 읽기 전용 감사 모두 blocker/high/medium/low 0이다. DB08 effect CAS부터 DB13 cleanup, provider effects, interfaces, orchestration, frontend, 실제 HQ actor, screenshot/WebP는 여전히 RED다. 따라서 DB07만 GREEN이며 P01 전체와 ADR 구현 상태는 계속 RED/partial이다.

DB08 RED 기록

criteria revision은 assembly 034f6da42dadd2d994744bbee3279f6fb4fd68ca, executable test revision은 backend 5e42e8d58d5377481b39a48ec3933289f146a37a다. production migration은 DB07 GREEN revision 그대로다.
완료 lineage 네 건과 repairable lineage 네 건을 JSON ordinality로 고정 순서 실행한다. exact actor/HQ/idempotency key/command/branch scope, expected state revision, expected effect status/reference, stored claim identity reference parity를 각 호출 전에 검증한다.
fresh tracked migration replay와 Supabase db lint error 0 뒤 첫 operator_identity_provisioning pending → completed가 exact 0A000과 branch onboarding transition is outside the enabled DB03 boundary를 반환했다. 테스트는 이 제품 실패를 성공으로 삼지 않고 P01-DB-EFFECT-CAS complete-operator-identity returned ...로 다시 실패한다.
실패 호출은 exception subtransaction에서 전부 rollback된다. 전후 private durable snapshot, raw target command/effect, 다른 모든 command/effect, 두 HQ revision, 열 가지 authority count, branch/office/office revision, audit, invitation, active membership, fee policy 전체가 동일함을 확인했다.
테스트 작성 중 발견한 schema-qualified coalesce 오류는 제품 RED 전에 제거했고, 최종 fresh run은 위 exact product failure까지 도달했다. 후속 독립 감사가 case 순서를 명시적 ordinality로 고정하고, identity reference를 stored claim과 관계식으로 묶고, missing JSON field도 통과하지 못하도록 null-safe 비교를 적용한 것을 재확인했다. blocker/medium 잔여는 0, disposable DB도 없다.
이 기록은 provider 실행 성공, DB08 production, DB09 거부 matrix, DB10 finalize, DB11 repair, DB12 scoped GET, DB13 cleanup, interface/orchestration/UI/actual actor 증거가 아니다. DB08과 P01은 RED다.

DB08 production candidate와 감사 재오픈 RED

backend production candidate a1f26f7ba27afcb43c0914f74e6d8cf29a5ffbaf은 새 schema/table/index/constraint 없이 기존 side-effect transition RPC 하나만 확장했다. original ordered eight-case matrix, full fresh tracked replay, Supabase lint, four authority races, 207 passed, Ruff, Tach를 통과했고 Vulture 세 후보는 durable Protocol parameter로 확인됐다.
독립 production 감사에서 manager-membership pending → retrying이 임의의 non-UUID reference를 받아들이는 Medium 반례를 찾았다. 해당 known reference는 이후 rewrite가 금지되고 completed 전이는 canonical UUID cast를 요구하므로 영구적으로 완료할 수 없는 poisoned state가 된다.
backend test b58ee8437cdb297ed8090f1e25c16d1146cc5ec6은 command/effect/private snapshot의 무변경까지 고정하고, unchanged candidate에서 P01-DB-EFFECT-CAS accepted poisoned manager retry reference를 정확히 재현한다.
같은 감사에서 raw JSON non-string의 ->> coercion과 PostgreSQL space-only btrim 대 application strip()의 tab/newline 차이도 찾았다. 위 순차 기준에서 malformed payload 무변경은 DB09 소유이므로 DB08 수정에 몰래 섞지 않는다. DB09 criteria 입력으로 기록할 뿐 아직 executable DB09 RED나 GREEN 증거는 아니다.
production은 candidate a1f26f7ba27afcb43c0914f74e6d8cf29a5ffbaf 상태로 유지된다. 최종 DB08 production fix와 재검증 전까지 DB08은 RED다. DB09 through DB13, 실제 provider, interface/orchestration/UI/actor/screenshot/WebP도 여전히 RED이며 P01과 ADR implementation은 계속 RED/partial이다.

DB08 final GREEN

audit RED 문서는 assembly a3755aabe03918cc6f31eaaa40168d5420cca8b9, 최종 production은 backend b63f8eb61e08dddd65bf8f80139c81931eade8ab이다. one-line fix는 manager-membership의 모든 non-null reference를 mutation 전에 canonical UUID로 검증한다. null-reference retry는 계속 허용하고 invitation insert는 completed일 때만 실행한다.
committed regression b58ee8437cdb297ed8090f1e25c16d1146cc5ec6은 non-UUID manager retry가 exact 22023/branch onboarding invitation reference is invalid로 거부되고 private snapshot, raw command, target effect가 모두 불변임을 검증한다. 두 제한 독립 감사는 blocker/medium 0이다.
fresh tracked Supabase replay와 db lint error 0, DB01-08 SQL smoke와 outer rollback을 통과했다. identity/email/branch-code/business-identity 네 race는 각각 winner=1 exact-loser=1 partial=0이고 helper schema와 disposable container는 남지 않았다.
P01 domain/application/adapter는 207 passed, Ruff check/format은 통과했다. Tach exact dependency/interface/external은 diagnostic 0이고 application은 domain에 의존하며 adapter가 application을 사용한다. external dependency는 sanmopia-python-contracts다. Vulture confidence 100 후보 세 건은 durable store Protocol 시그니처 parameter라 삭제하지 않았다.
DB09 malformed/stale/rewrite/cross-scope rejection부터 DB13 cleanup, 실제 provider, interface/orchestration/UI/actor/screenshot/WebP는 여전히 RED다. 따라서 DB08 persistence만 GREEN이고 P01과 ADR implementation은 계속 RED/partial이다.

DB09 executable RED

criteria 원본은 assembly a51e3ccd6f3272282fe148cf6e36727751b8ad80, 전수 matrix amendment는 assembly d051bf1cb82fc566f5050df83e60e624f6d7e49a다. executable RED는 backend a14180ade1d71752bf77641650dde3541a7d7194; production은 DB08 GREEN b63f8eb61e08dddd65bf8f80139c81931eade8ab에서 바꾸지 않았다.
ordered gate는 explicit 46, payload JSON type 6 x 4 = 24, payload canonical text 3 x 3 x 2 = 18, execution scope canonical text 5 x 3 x 2 = 30, 합계 118 case다. label/position 충돌은 없고 DB08 본문은 byte-identical이다. DB10부터 DB13은 주석 외에 열지 않았다.
fresh tracked Supabase replay와 public schema lint error 0, DB01-08을 통과한 뒤 현 RPC가 referenceId: 123을 ->>로 "123"에 coercion해 pending invitation-delivery retry를 수락했다. exact 첫 product RED는 P01-DB-EFFECT-REJECT accepted non-string-reference다.
unexpected success와 test-only expected-reference fixture는 같은 exception subtransaction 안에 있다. 성공 mutation/setup은 상태 비교 전에 rollback되고, case 직전 캡처한 두 private snapshot, raw command/effect, branch, office/revision, HQ revision, invitation, membership, fee policy, audit의 전체 row/count/timestamp와 exact 동일하다. outer transaction과 disposable DB도 남지 않았다.
독립 matrix/계약 감사와 harness/rollback 감사 결과는 각각 blocker 0, medium 0이다. 이는 DB09 production GREEN 증거가 아니다. 다음 변경은 JSON 실제 타입 검증, Python strip()과 같은 scope/payload canonical text 검증, raw P0002를 exact scope mismatch로 매핑하는 최소 RPC 수정뿐이다. 이 시점의 118 case와 기존 회귀를 같은 production revision에서 통과하기 전까지 DB09와 P01은 RED라는 판정이었다. 아래 Unicode 감사가 이 acceptance 크기를 534 case로 상향한다.

Unicode canonical parity audit reopening

production GREEN 전 독립 감사에서 118-case matrix가 Python str.strip() 전체 경계가 아니라 ASCII space/tab/newline만 대표했다는 medium 반례를 찾았다. NBSP U+00A0로 감싼 text는 Python application에서 거부되지만 ASCII-only PostgreSQL 후보에서는 유지되어 reference/failure 저장이나 scope lookup까지 진행할 수 있다.
따라서 앞선 118-case 통과는 폐기하지 않고 ASCII 하위집합 증거로만 유지한다. acceptance는 explicit 46 + JSON type 24 + payload Unicode canonical 174 + scope Unicode canonical 290 = 총 534 case로 상향한다. 이 criteria amendment와 새 executable RED를 production commit보다 먼저 만든다.
현재 ASCII-only production candidate는 커밋하지 않으며 DB09는 다시 RED다. 29-code-point matrix의 정확한 실패와 whole-state rollback을 고정한 뒤에만 PostgreSQL boundary predicate를 수정한다.
Unicode criteria revision은 assembly 568ae08c5e41ae530b4ae67bf9315ddfb881b396, expanded executable RED는 backend f3cdf330ad9f44036f21894e0400365be3652153이다. SQL은 Python 3.13.5 str.isspace()를 독립 열거한 29 code point와 exact 일치하고 position/label 충돌이 없다.
fresh tracked replay, public schema lint error 0, DB01-08 뒤 ASCII-six 후보가 U+001C-leading expected reference를 수락했다. exact RED는 P01-DB-EFFECT-REJECT accepted canonical-expected-reference-u001c-leading이다. test-only fixture와 성공 mutation은 exception subtransaction에서 rollback되어 전체 row/timestamp가 case 직전과 동일하고 disposable DB는 남지 않았다.
matrix/contract 감사와 harness/fixture 감사 모두 blocker 0, medium 0이다. 이 revision은 Unicode parity production GREEN이 아니다. PostgreSQL이 같은 29-code-point boundary를 거부하고 534 case와 전체 회귀를 통과할 때까지 DB09와 P01은 RED다.

DB09 final GREEN

production revision은 backend 243a674ed5ad4e456e0c8cb55ca50ed9127cbe96이다. 기준 revision assembly 568ae08c5e41ae530b4ae67bf9315ddfb881b396과 expanded executable RED backend f3cdf330ad9f44036f21894e0400365be3652153보다 뒤에 있어 RED → 최소 수정 계보를 보존한다.
transition RPC는 여섯 raw JSON field를 string 또는 허용된 string|null로 text 추출 전에 검사한다. scope 다섯 field와 expected/reference/failure text에는 Python 3.13 str.isspace()와 exact 일치하는 29-code-point btrim 집합을 적용한다. command scope no-row만 exact 22023 branch onboarding transition scope mismatch로 바꾸며 command/effect row lock, state/status/reference CAS, operator identity reference 검증, SECURITY DEFINER, 빈 search_path, service-role-only 실행은 유지한다.
final fresh tracked Supabase run은 public schema lint error 0, DB01-09, DB09 534 case, whole-state rejection immutability, 성공/fixture exception subtransaction rollback, outer rollback을 모두 통과했다. identity/email/branch-code/business-identity 네 race는 각각 winner=1 exact-loser=1 partial=0이고 helper schema와 disposable container는 남지 않았다.
P01 domain/application/adapter는 207 passed, Ruff check/format은 통과했다. Tach exact dependency/interface/external diagnostic은 0; application → domain, adapter → application 방향과 external sanmopia-python-contracts가 확인됐다. Vulture confidence 100의 세 후보는 durable-store Protocol signature parameter라 삭제하지 않았다.
product와 harness를 나눠 본 최종 독립 감사 두 건 모두 blocker 0, medium 0이다. custom image build, 온라인 배포, screenshot/WebP 수집은 없는 DB-only gate였다. DB10 finalize부터 DB13 cleanup, provider/interface/orchestration/UI/actual actor evidence는 여전히 RED다. 따라서 DB09 persistence만 GREEN이고 P01과 ADR implementation은 계속 RED/partial이다.

DB10 executable RED

DB10 criteria는 assembly 5ee6aa6b282ef92978edb7ef658e5140985514c7, strict result 계약은 contract 918d797c578df43edc6697a85ab3016409bb75ee에 먼저 고정했다. 그 뒤 executable test-only revision backend 56d87be190fa4897b80884eb382c369c5e1b6a7a를 만들었다. product migration blob은 5cf6c6a6002e365fb0280fdbe8c7631a7f91d702 그대로이므로 이 revision은 production fix나 DB10 GREEN 증거가 아니다.
serial corpus는 aggregate ledger가 검증하는 총 2,107 case다. 분류는 rejection 2,094, nullable repair.nextRetryAt 유효 성공 1, 최초 write 2, exact/order-only replay 10이다. 이 숫자는 executable case 정의와 중복 없는 label 합계다. 아래 RED 실행은 RPC 부재 sentinel에서 순차 중단했으므로 2,107 case가 이번 명령에서 실행됐다는 뜻이 아니다.
실행 명령은 다음과 같다.
Terminal window
```
pnpm run -s supabase:test:local-branch-onboarding-durable-store
```
fresh tracked migration replay 뒤 public schema lint와 DB01-09 SQL은 통과했고, 첫 DB10 action은 exact ERROR: P01-DB-FINALIZE missing finalize RPC로 종료 코드 3을 반환했다. Supabase CLI의 migration-catalog 조회 중 Tokio warning도 있었지만 reset, lint, DB01-09 smoke는 계속 진행됐으므로 product RED로 세지 않는다.
append 전 DB09 prefix SHA-256은 6b25ce68293f595382962d93205c4c88a9a21c09cf2cc3ae90963317b2b25c06으로 원본과 exact 일치한다. 실행 뒤 disposable container 0, 관련 /tmp artifact 0을 확인했다.
same/different finalize race harness는 test revision에 고정했지만 strict sequential RED 규칙상 missing-RPC sentinel 뒤에는 실행하지 않았다. 최소 production RPC가 이 첫 RED를 닫은 뒤에만 serial 2,107 case와 두 finalize race를 포함한 DB01-10 full regression을 실행한다. 따라서 현재 race winner/replay/immutable-loser 결과를 주장하지 않는다.
최종 독립 serial/contract 및 race/harness 감사 결과는 Blocker 0, Medium 0이다. 이는 RED harness의 완전성 판정이지 production 통과 판정이 아니다. DB11-13, provider, interface, orchestration, UI, actual actor, screenshot, animated WebP는 계속 RED다. 온라인 배포도 없었다.

DB10 production GREEN

production 후보 감사에서 JSON schema 문자열의 U+FEFF가 PostgreSQL 기본 btrim을 우회하는 반례를 찾았다. backend a7cdbf6d951082530569dc9989903214d5f9a7c4가 41개 non-null 문자열 path에 FEFF RED를 먼저 고정했고, 첫 실패는 P01-DB-FINALIZE string-completed-command-id-ufeff returned 22023 / branch onboarding final result does not match durable state였다. production은 이 문자를 schema whitespace 집합에만 추가하고 execution scope의 기존 Python 29-code-point parity는 바꾸지 않았다.
production d40871109eb156c1f3ac53986f2ae310ddd4b3c9은 strict 25-key result를 검증한 뒤 relationship/effect/action을 canonicalize하고, command row FOR UPDATE, accepted-before-CAS replay, durable command/audit/journal parity, accepted/current 단일 update를 한 SECURITY DEFINER·빈 search_path·service_role 전용 RPC로 닫는다.
serial ledger는 총 2,148 case다: rejection 2,135, rollback-success 1, first-write 2, exact/order-only replay 10. FEFF 포함 문자열 matrix만 41 × 31 = 1,271 case이며 모든 rejection은 whole-state와 timestamp 불변을 확인한다.
최종 pnpm run -s supabase:test:local-branch-onboarding-durable-store는 fresh tracked migration, public schema lint 0, DB01-10 serial 전체, outer rollback을 통과했다. 동일 payload race는 first=1 replay=1 revision-increment=1 partial=0, 다른 valid payload race는 winner=1 immutable-loser=1 revision-increment=1 partial=0이다. 기존 identity/email/branch-code/ business-identity 네 race도 각각 winner=1 exact-loser=1 partial=0; source baseline은 exact 보존됐다. Supabase CLI migration-catalog Tokio warning은 reset/lint/smoke를 막지 않은 비제품 경고다.
최초 race clone은 Supabase background worker 연결 때문에 실패했고, 관리자 clone + postgres ownership으로 교정했다. 최종 cleanup 감사가 찾은 mutation-ACK 간극도 cleanup flag를 mutation 전에 무장해 닫았다. harness commit은 a7b45a22d903f1b6669c1f996d6b2c06a561a9fe; 종료 뒤 clone, container, 관련 /tmp artifact는 모두 0이다.
branch-onboarding Python 207 passed; clean backend HEAD 전체는 5,663 passed, 1 failed다. 유일한 실패는 DB10 이전 platform validator가 모든 migration을 합친 뒤 auth.role()을 문맥 없이 금지하고 SECURITY DEFINER를 한 개만 허용하는 낡은 gate다. 현재 repo에는 48개 function definition과 comment 한 건이 있어 별도 policy/parser 기준 없이 체크를 약화하지 않는다. Layer-first package marker 누락 두 건은 backend 8a94ad7b6c77aac6e20eb6fed81d33d664558837에서 고쳐 architecture 13개가 통과했다. Tach dependency/interface/external diagnostic은 0; focused Vulture의 confidence 100 세 건은 durable-store Protocol parameter라 삭제하지 않았다.
최종 독립 contract 및 security/race 재감사는 Blocker 0, Medium 0이다. custom image build와 Buildx 대상은 없었다. 테스트에 사용한 공식 Supabase image 세 개는 최종 검증 뒤 제거했다. 온라인 배포, screenshot, WebP 수집은 하지 않았다. DB10 persistence만 GREEN이며 P01과 ADR 구현 상태는 계속 RED/partial이다.

DB11 criteria pin

시작 상태와 단일 write 경계

새 public repair RPC를 만들지 않는다. DB08-09가 사용한 기존 public.sanmopia_record_branch_onboarding_side_effect_transition(text,text,text,text,text,integer,jsonb,jsonb) 하나를 post-acceptance repair에도 연다. 반환은 durable snapshot_payload이며 replay flag를 새로 추가하지 않는다. SECURITY DEFINER, 빈 search_path, fully-qualified object, service_role 전용 EXECUTE도 그대로 유지한다.
입력은 DB10 repairable lineage다: actor hq-admin-p01-2, HQ 00000000-0000-0000-0000-000000000702, key p01-key-2, command branch-command-p01, branch 00000000-0000-0000-0000-000000000712, command state revision 6. accepted와 current는 같은 strict repair-pending payload이고 identity만 completed, authorization은 retrying, manager membership/invitation/fee는 pending이다.
command row를 먼저 FOR UPDATE하고 exact five-part scope와 expected revision을 확인한다. 선택한 effect의 expected status/reference를 FOR UPDATE로 CAS한 뒤, transition을 적용한 candidate journal과 제출된 full current payload를 검증한다. mutation 전 stored current도 accepted lineage와 현재 journal에 exact parity여야 한다. 성공 transaction 하나가 바꿀 수 있는 것은 선택한 journal 한 행의 status/reference/failure/updated_at, command의 state_revision/current_result_payload/ updated_at, 그리고 manager-membership 완료 때의 exact invited invitation row뿐이다.
DB10 finalize는 transaction timestamp보다 늦은 clock_timestamp()를 command에 기록한다. 따라서 post-acceptance repair가 now()로 되돌아가면 timestamp가 역행한다. DB11 target command/effect updated_at은 clock_timestamp()로 각각 이전 값보다 strict 전진해야 하고 네 unselected effect와 다른 row timestamp는 byte-identical이어야 한다.
accepted_result_payload, actor/HQ/key/command/branch, prepared identity claim, request/plan, fingerprint, audit, branch/office/office revision/HQ revision, 네 unselected journal effect, active membership과 기존 fee authority는 byte-identical이다. accepted와 current의 저장 idempotentReplay는 항상 false다.
sanmopia_branch_memberships row 하나가 곧 active P02 authority다. P02 activation command가 아직 없으므로 authenticated와 service_role의 effective table 권한은 SELECT만 허용한다. direct service_role INSERT는 exact 42501이고 whole P01 state와 membership count는 불변이어야 한다. P02는 onboarding command revision을 공유하는 narrow activation RPC를 먼저 RED→GREEN한 뒤에만 연다.

A-Z repair sequence

먼저 rollback-success probe 하나가 revision 6에서 authorization을 retrying → retrying으로 전진시킨다. known reference와 stable repairId를 보존하고 failure code와 nullable canonical nextRetryAt만 갱신한 strict current, revision 7을 안쪽에서 검증한 뒤 sentinel exception으로 전부 rollback한다. 이 probe는 아래 main lineage의 revision 6을 소비하지 않는다.

revision 6 → 7: authorization effect retrying → completed, reference relationship-write-p01-2 보존, failure null, authorizationRelationshipStatus=active. 나머지 세 incomplete effect 때문에 current는 repair_pending, non-null repair, exact [inspect_onboarding_repair]다.
revision 7 → 8: manager-membership effect pending → completed, canonical UUID reference를 managerMembershipId로 투영하고 managerMembershipStatus=invited로 만든다. 같은 UUID의 sanmopia_branch_manager_membership_invitations row 하나만 invited로 생성하며 active sanmopia_branch_memberships row는 만들지 않는다.
revision 8 → 9: fee effect pending → completed, exact policy reference, revision 1, status published를 current에 함께 기록한다. invitation effect가 아직 pending이므로 current는 repair_pending, stable repair ID, exact inspect action을 유지한다.
revision 9 → 10: manager-invitation effect pending → completed, exact delivery reference와 managerInvitationStatus=sent를 current에 함께 기록한다. 이 effect를 마지막에 완료해야 public contract의 sent-invitation 3-action 규칙과 repair-pending singleton-action 규칙이 충돌하지 않는다. 다섯 effect가 모두 completed가 되면 current만 outcomeStatus=completed, repair=null, exact [complete_branch_profile,configure_service_area,resend_manager_invitation]가 된다. DB10 accepted는 계속 original repair-pending payload다. P02가 소유하는 membership active나 invitation accepted는 DB11 어느 단계에서도 허용하지 않는다.

각 단계의 current는 criteria-pin contract 918d797c578df43edc6697a85ab3016409bb75ee의 closed 25-key shape, closed five effects, nullable closed repair, raw JSON type, canonical string, enum, aggregate/effect parity를 모두 만족해야 한다. 현재 artifact 1f56d28b31a0a5f16045e41bb4555e7eb20e3745도 이 canonical schema를 바꾸지 않는다. relationship/effect/action 배열은 DB10과 같은 canonical set order로 저장한다. unfinished current의 repair envelope는 coordinator-owned current 입력이지만 repairId는 accepted와 같은 repair lineage로 고정한다. nextRetryAt만 canonical millisecond UTC 또는 null로 재스케줄할 수 있다. accepted의 repair envelope는 어떤 repair에서도 다시 쓰지 않는다. current 문자열 경계도 DB10과 같이 Python str.isspace() 29개 문자와 U+FEFF를 모두 blank로 처리하며, empty를 포함한 전수 matrix를 재사용한다.

criteria pin 당시 provider-neutral application _require_result_lineage는 current의 다른 repairId도 수용했다. 첫 SQL 0A000 RED 뒤 colocated changed-repair-ID RED 5d3cc793671e9da547fb3449cffccc7821d559f3와 최소 GREEN 60053a89240bbf3a5d4ec7fdad97cd6ce635d2b0으로 repair ID 일치를 강제했고, nextRetryAt 변경 성공은 보존했다.

또한 canonical JSON Schema는 managerInvitationStatus=sent에 completed 3-action set을 요구하므로 unfinished repair_pending/inspect singleton과 함께 존재할 수 없다. 그래서 invitation delivery가 마지막 repair다. criteria pin 당시 generated TypeScript/Python validator는 이 cross-branch 규칙을 빠뜨려 sent+unfinished payload를 수용했다. 첫 SQL RED 뒤 RED 88a0688e68532cf14975b85b90947da351d00987과 GREEN artifact 1f56d28b31a0a5f16045e41bb4555e7eb20e3745로 JSON Schema를 넓히지 않고 일치시켰다. 고정된 순서는 contract parity GREEN → application repair-lineage GREEN → SQL production이다.

replay, rejection, rollback, race

repair transition은 CAS write다. 동일 transition을 이미 소비한 old expected revision으로 다시 보내면 exact 40001 branch onboarding durable state changed concurrently이며 모든 row와 timestamp가 불변이다. snapshot-only repair RPC에 delivery replay 의미를 새로 만들지 않는다.
P01 exact replay는 네 repair 뒤 original DB10 repair payload를 original pre-finalize revision 5로 finalize 재호출해 검증한다. 반환 accepted는 original repair-pending payload, delivery idempotentReplay=true다. repaired current, revision 10, journal, invitation, 모든 timestamp는 byte-identical이어야 한다.
malformed transition envelope는 기존 exact 22023 branch onboarding transition input is invalid, six-field transition 의미 위반은 기존 exact 22023 branch onboarding transition payload is invalid를 유지한다. malformed current, stored replay variant, accepted immutable-field rewrite, repair ID 교체, non-target effect drift, aggregate/effect mismatch, current snapshot의 accepted/non-target reference rewrite, current-side completed-effect regression, outcome/repair/action 모순, P02 manager state는 exact 22023 branch onboarding current result is invalid와 whole-state 불변이다. scope mismatch는 기존 exact 22023 branch onboarding transition scope mismatch, stale command/effect CAS는 exact 40001을 유지한다. malformed stored current/journal/accepted parity는 exact XX000 branch onboarding stored current result is invalid, completed accepted에 대한 repair는 exact 0A000 branch onboarding transition requires repair-pending acceptance다. 이 eligibility guard가 먼저며, repair-pending accepted command에 null current를 제출한 경우만 exact 0A000 branch onboarding repair requires current result로 mutation 전에 fail closed한다.
guard 이동 회귀를 별도 고정한다. accepted/current가 아직 null인 DB08 lineage에 valid transition과 non-null strict current를 함께 제출하면 기존 exact 0A000 branch onboarding transition requires pre-acceptance state이고 whole-state/timestamp는 불변이다.
동시 repair는 smoke rollback과 독립된 committed repairable lineage와 cloned disposable database를 사용한다. revision 6에서 authorization-completion 후보와 manager-membership-completion 후보를 각각 독립 success/rollback으로 먼저 증명한 뒤 두 session을 같은 target command-row barrier에 모은다. 결과는 winner 1, exact 40001 branch onboarding durable state changed concurrently loser 1, command revision increment 1, accepted unchanged, winner journal/current pair 1, loser effect untouched, loser partial 0이어야 한다. manager winner이면 invited invitation 1/active membership 0, manager loser이면 invitation 0이다. always-run cleanup은 clone/container/temp artifact를 제거하고 source baseline을 검증한다.

첫 executable RED

문서 criteria revision이 backend test revision보다 먼저 와야 한다. committed backend baseline은 8a94ad7b6c77aac6e20eb6fed81d33d664558837, contract는 918d797c578df43edc6697a85ab3016409bb75ee, product migration Git blob은 ac31182989298d47a8199e5b37a9522562414570로 고정한다. DB11은 outer transaction의 terminal rollback; 앞에 실행돼야 하므로 기존 파일 전체가 current file의 literal prefix라고 주장하지 않는다. DB10 마지막 두 boundary comment까지의 literal preserved body SHA-256은 fe64061ccccbf1de703f7892b28210e4fcfda1ed7dd302cf635be6b70d2ba8a8이고, 그 body에 blank line과 terminal rollback;을 복원한 pre-DB11 full baseline SHA-256은 4b6aa8267f9c5e48b98372e4e816db403656e04d6d49cbf3f0b89583a206f8bf다. 이들을 바꾸지 않고 DB10 serial ledger가 끝난 직후 valid authorization retrying → completed transition과 그 candidate를 반영한 non-null current를 기존 RPC에 제출한다.
이 RED revision의 DB10 production은 exact 0A000 branch onboarding transition requires pre-acceptance state로 거부해야 한다. test는 호출 전후 whole durable state를 비교한 뒤 exact sentinel P01-DB-REPAIR complete-retrying-authorization returned 0A000 / branch onboarding transition requires pre-acceptance state 로 중단한다. 이 sentinel이 닫히기 전 DB11 full corpus나 race 통과를 주장하지 않는다.
DB11은 persistence repair만 연다. provider 실행, Restate orchestration, DB12 scoped GET, DB13 cleanup, interface/UI/actual actor/screenshot/WebP, 온라인 배포는 계속 RED다.

DB11 executable RED

criteria는 assembly 3b5baff5e114699438495d35f6bd4bb8149ec97c, terminal rollback 앞 삽입의 hash 의미 보정은 assembly 1e67657245042d7a65fa992c81ced479b993a045에 production보다 먼저 고정했다. executable test-only backend revision은 82568de35df5099c429b5261df33bba3befd9ab9다.
backend RED는 smoke에 112줄만 append했다. product migration Git blob ac31182989298d47a8199e5b37a9522562414570, preserved DB10 body SHA-256 fe64061ccccbf1de703f7892b28210e4fcfda1ed7dd302cf635be6b70d2ba8a8, terminal rollback을 복원한 full baseline SHA-256 4b6aa8267f9c5e48b98372e4e816db403656e04d6d49cbf3f0b89583a206f8bf가 모두 exact다.
공식 digest 고정 Supabase PostgreSQL/Storage image를 다시 pull한 뒤 pnpm run -s supabase:test:local-branch-onboarding-durable-store를 fresh 실행했다. public schema lint 0, DB01-10과 DB10 serial 2,148 case가 먼저 통과하고 exact P01-DB-REPAIR complete-retrying-authorization returned 0A000 / branch onboarding transition requires pre-acceptance state 에서 순차 중단됐다. migration-catalog Tokio warning은 reset/lint/smoke를 막지 않은 기존 비제품 경고다.
valid candidate는 authorization effect만 known reference를 보존해 retrying → completed하고 aggregate status만 active로 맞춘 strict repair-pending current다. inner exception subtransaction은 unexpected success도 rollback하며, 실패 전후 10개 authority 집합의 전체 to_jsonb와 timestamp가 byte-identical이다. 종료 뒤 disposable DB/storage container와 관련 temp directory는 0이다.
두 독립 read-only 감사 결과는 Blocker 0, Medium 0이다. 이 실행은 첫 product gap만 증명한다. DB11 full rejection/success corpus와 repair race는 sentinel 뒤 실행되지 않았고 production은 unchanged다. 다음 순서는 generated TS/Python sent+unfinished parity RED→GREEN, application stable-repair-ID RED→GREEN, 그 뒤 SQL production이다. DB12-13과 provider/interface/UI/actual actor도 계속 unopened다.

DB11 generated-client parity GREEN

test-only contract 88a0688e68532cf14975b85b90947da351d00987는 invitation effect를 completed로 맞추고 다른 effect를 unfinished로 남긴 sent와 accepted 두 반례를 고정했다. Canonical JSON Schema는 둘 다 거부하지만 기존 TypeScript validator는 problem [], Python은 DID NOT RAISE로 실패했다.
product e16c642d39d879fe71b27d2edc52fb1ac281bf1f는 두 generated validator의 repair-pending 분기에 delivered invitation 거부만 추가했다. schema/OpenAPI diff는 0이고, completed 분기는 바꾸지 않았다. tracked artifact는 1f56d28b31a0a5f16045e41bb4555e7eb20e3745다.
focused TypeScript 7/7, Python P01 14/14, 전체 Jest 48 suites / 431 tests, Python contract 37/37, layout/lint/TypeScript build가 통과했다. Vulture 100% confidence 후보는 0, 독립 감사는 Blocker 0, Medium 0이다.
이 stage에서는 contract parity만 GREEN이었다. application stable-repair-ID와 DB11 SQL은 뒤의 순차 gate에서 닫혔고, DB12-13과 provider/interface/orchestration/UI/actual actor/screenshot/WebP는 계속 RED다.

DB11 application repair lineage GREEN

test-only backend 5d3cc793671e9da547fb3449cffccc7821d559f3는 accepted/current가 모두 repair-pending일 때 changed repairId가 기존 application snapshot에 수용되는 DID NOT RAISE RED를 고정했다. 같은 repair ID에서 canonical timestamp 또는 null로 nextRetryAt을 바꾸는 두 case는 의도한 허용 기준으로 통과한다.
product 60053a89240bbf3a5d4ec7fdad97cd6ce635d2b0은 Layer-first application durable snapshot lineage에 stable repair ID 비교 1개만 추가한다. nextRetryAt은 비교하지 않고, completed current의 contract-required null repair도 허용한다.
exact 1/1, durable-store focused 58/58, domain/application/adapter branch-onboarding 210/210, Ruff, Tach dependencies/interfaces/exact/external 진단 0이 통과했다. Vulture 100%-confidence 후보 5는 모두 durable-store Protocol 메서드 인자임을 확인해 삭제하지 않았다.
이 stage에서는 application invariant까지 GREEN이었다. DB11 SQL은 다음 순차 gate에서 닫혔고, DB12-13과 provider/interface/orchestration/UI/actual actor/screenshot/WebP는 계속 RED다.

기존 sanmopia_branch_profiles, sanmopia_branch_office_profiles, sanmopia_branch_membership_fee_policies의 service_role CRUD는 이미 다른 승인된 backend feature가 사용하므로 이 migration에서 전역 revoke하지 않는다. service_role은 actor/client credential이 아닌 trusted backend credential이며 public P01 command는 atomic RPC만 사용한다. P01 내부 다섯 authority table은 direct CRUD를 허용하지 않는다. 공유 table의 전역 RPC-only 전환은 모든 기존 consumer를 함께 이관하는 별도 platform gate다. 단, sanmopia_branch_memberships는 현재 writer가 없고 row 자체가 active P02 authority이므로 ADR-030의 DB11 결정에 따라 direct mutation을 닫고 SELECT만 복원한다. 미래 P02 activation RPC도 이 권한을 다시 넓히지 않는다.

DB11 SQL GREEN

criteria와 executable RED 뒤 test-only backend revisions a49915c, 793891d, c6f8128, 659942c, 53ff351이 A-Z serial corpus, guard precedence, stored-state corruption, 실제 두 session CAS race, membership direct-DML 거부를 순서대로 고정했다. Membership authority 보강 ADR c2d8d70도 product보다 먼저 accepted 됐다.
product backend c23c5bb5e235e71432a611510d3ce9a785b567d6는 기존 side-effect transition RPC만 확장한다. accepted payload는 보존하면서 authorization → invited manager authority → fee publication → invitation delivery를 revision 6 → 10으로 원자 전진한다. 별도 repair RPC, replay flag, active membership write는 없다.
pinned official Supabase PostgreSQL의 persistent selected-migration workspace에서 CLI db reset은 최근 6.8s, public schema lint 결과는 []였다. DB10 2,148 + DB11 1,571, 누적 3,719 serial case와 outer rollback이 통과했다. 최종 fresh canonical gate도 serial corpus, DB10/DB06/DB11/DB07 race, disposable teardown을 다시 통과하고 exact full-scope acceptance sentinel을 반환했다.
실제 두 backend repair race는 revision=6 contenders=2 lock-waiters=2 winner=1 sqlstate-40001=1 revision=7 current-journal-atomic=1 loser-partial=0 invitation-leak=0이다. source baseline과 disposable clone teardown도 exact다.
branch-onboarding Python 211 passed, Ruff와 Tach diagnostic 0, Vulture 100%-confidence 후보 0이다. product SQL 감사와 ADR/criteria 재감사는 모두 Blocker 0, Medium 0이다.
DB11만 GREEN이다. DB12 scoped GET, DB13 cleanup, provider effects/compensation, interfaces, orchestration, frontend, actual actor, screenshot/WebP와 온라인 배포는 계속 RED다. image pull과 custom build는 없었다.

DB12 scoped GET criteria pin

기존 application query는 caller에게 commandId만 받고 authority resolver가 authenticated subject에서 actor/HQ를 만든다. 기존 adapter 78781cff20216ebd13a0918be1319e72143b94dc가 호출하는 유일한 SQL surface는 public.sanmopia_get_current_branch_onboarding_result(text,text,text)다. 반환 row key는 exact actor_id, headquarters_branch_id, command_id, result_payload다.
function은 STABLE SECURITY DEFINER, empty search_path, service_role EXECUTE-only다. public, anon, authenticated는 EXECUTE할 수 없고 onboarding table direct privilege는 추가하지 않는다.
mutable command의 accepted payload는 자기 자신의 진위를 증명할 수 없다. DB12 내부 authority amendment는 FK 없는 private.sanmopia_branch_onboarding_accepted_results에 first finalize의 exact accepted payload를 같은 command lock/transaction에서 한 번만 기록한다. table은 UPDATE/DELETE trigger로 append-only이고 Data API table privilege가 없으며 private assert/snapshot helper EXECUTE도 모두 revoke한다.
inspect, start/replay, transition/repair, finalize/replay, GET은 accepted 상태를 반환하거나 변경하기 전에 command accepted와 independent receipt가 byte-equal인지 검사한다. pre-acceptance는 command null + receipt 없음만 허용한다. missing/divergent receipt는 exact XX000 fail-closed이고 transition/GET은 기존 branch onboarding stored current result is invalid 외부 계약을 유지한다.
actor는 nonblank canonical text, HQ는 round-trip exact UUID text, command는 nonblank canonical text 최대 200자다. Python 29-whitespace와 U+FEFF 양끝을 application, adapter, SQL 모두 같은 기준으로 거부한다. invalid SQL input은 exact 22023 branch onboarding result query input is invalid다.
missing command, actor mismatch, HQ mismatch, command mismatch, pre-acceptance null current는 모두 정보 누출 없이 zero rows다. valid repair-pending/current와 completed current는 각각 한 row다. DB11 완료 뒤에도 accepted repair-pending이 아니라 completed current_result_payload를 반환한다.
반환 전 accepted/current object, current replay JSON false, command row와 payload의 actor/command/ branch/fingerprint, accepted immutable lineage, canonical five journal effect parity를 검증한다. 위반은 exact XX000 branch onboarding stored current result is invalid다. full closed public schema는 기존 adapter가 다시 검증한다.
모든 success/not-found/rejection 호출 전후 command, journal, invitation, membership, audit, branch, office, organization revision과 모든 timestamp가 byte-identical이어야 한다. row lock, revision advance, audit append도 금지한다.
첫 executable RED는 product migration blob을 보존한 채 to_regprocedure 부재를 확인하고 exact P01-DB-GET missing scoped current-result RPC에서 중단한다. 이 sentinel 전에는 DB12 corpus나 GREEN을 주장하지 않는다. DB13/provider/interface/orchestration/UI/actual actor는 열지 않는다.

DB12 scoped GET GREEN

criteria는 assembly f3f7124cf3accad1fe28ec6a97bf74f3015789b2, 첫 executable RED는 backend 5ca37d81389d24c02308f9149113def690b8680a다. 26-case corpus c4b1fdac7b6b89424642c03335b84b5d38b22ab8와 initial GET product ef1a97647947e37a46ff958a1933e8d779f8a0c1 뒤 독립 감사에서 mutable accepted payload가 자기 provenance를 증명하는 순환을 발견했다.
hardening tests ab386921945868b5a733e3bb00954de0e634fc86가 accepted corruption, first-finalize receipt race, repair receipt immutability, repair-pending/completed success, U+FEFF, pre-acceptance whole-state 검증을 먼저 고정했다. Product 3d2cc841ddb0abc06a2e963c67640854eda59996가 private append-only receipt와 모든 accepted consumer guard를 추가했다. Application/adapter FEFF 불일치는 RED 448c326b9355ee429b00bb45cfd986c74c3d7880 뒤 final product 264f1baea39acdbc9982bddbb4bf799ca01de0a6에서 SQL과 일치시켰다.
DB12 executable ledger는 정확히 26 = 1 catalog + 2 success + 5 not-found + 18 rejection이다. repair-pending current와 completed current를 각각 실제 SQL success로 읽고, wrong actor/HQ/command와 pre-acceptance는 uniform zero-row다. service-role 직조회는 42501, receipt UPDATE/DELETE는 55000, malformed stored authority/current는 XX000으로 fail-closed한다. 모든 호출 전후 전체 command/journal/receipt/invitation/membership/audit/branch/office/HQ revision과 timestamp가 동일하다.
fresh pnpm run -s supabase:test:local-branch-onboarding-durable-store는 public schema lint [], serial corpus/outer rollback, DB10 finalize race, DB06 identity/email race, DB11 repair race, DB07 branch-code/ business-identity race, source-baseline/clone/container/temp teardown을 통과하고 exact P01 branch onboarding durable-store local Supabase acceptance passed scope=full을 반환했다.
branch-onboarding Python 218 passed, Ruff와 Tach diagnostic 0이다. Vulture 100%-confidence 후보 3은 테스트가 exact signature를 검사하는 required durable-store Protocol parameter라 삭제하지 않았다. 최종 product 독립 감사 Blocker 0, Medium 0; accepted-history 범위 governance blocker는 ADR-030 amendment로 닫았다.
이 GREEN은 DB12 persistence까지만 증명한다. DB13 cleanup, provider effects/compensation, interfaces, orchestration, frontend, 실제 HQ actor, screenshot/WebP와 온라인 배포는 RED다. image pull이나 custom build도 없었다.

DB13 cleanup criteria pin

DB13은 새 P01 business/public cleanup operation을 만들지 않는다. Assembly가 이미 소유한 sanmopia_test_data_batches/sanmopia_test_data_references provenance와 기존 sanmopia_reap_registered_stage_test_data_reference stage reaper를 재사용한다. public P01 OpenAPI, application port, adapter에는 cleanup surface를 추가하지 않는다.
삭제 권위는 이름, UUID 모양, 생성 시각, stage라는 문자열만으로 추론하지 않는다. fixture가 쓰기 전에 만든 exact batch와 reference만 test-owned다. batch는 environment_name=stage, owner_tag=sanmopia_stage_smoke, exact source script, cleanup_status=active, 만료된 TTL을 가져야 하고, delete reference의 expected_owner_tag는 batch owner와 같아야 한다. reaper는 materialized deployment identity가 stage인 DB에서 service_role만 실행한다.
DB13 target은 DB11 repair를 마치고 DB12 GET으로 읽힌 completed lineage 하나다. provider/Restate retry는 cleanup transaction 전에 quiesce됐다고 전제한다. 이 gate는 late provider retry를 막는 production tombstone이나 pre-acceptance/부분 provider fixture cleanup을 대신 증명하지 않는다. stage teardown은 해당 test run의 idempotency scope를 종료하며, cleanup 뒤 같은 HQ/key의 business replay 의미는 보장하지 않는다. production에서는 reaper가 비활성이고 이 key 정책 변화가 없다.
manifest는 exact target 네 개를 등록한다. cleanup order는 onboarding command 900, exact fee policy 800, office 700, core branch 600이다. command 삭제가 journal 다섯 건과 invitation을 cascade하고, office 삭제가 office revision과 남은 office child를 cascade한다. fee는 office cascade에 숨기지 않고 먼저 exact reference로 삭제한다. core branch는 non-cascade command/office FK가 사라진 뒤 마지막에 삭제한다. 예상 밖 inbound FK는 넓은 cascade로 우회하지 않고 23503으로 전체 transaction을 fail-closed한다.
P01은 invitation-only이므로 target active membership은 cleanup 직전과 직후 모두 정확히 0이어야 한다. membership이 있으면 조용히 지우지 않고 P01 authority 위반으로 실패한다. created Auth identity, SpiceDB parent_hq/hq_admin/branch_operator 관계와 파생 manage permission 삭제는 DB13 밖의 assembly-owned full stage cleanup에서 같은 test ownership으로 검증한다. attached Auth identity는 삭제하지 않는다.
public audit와 private accepted-result receipt는 각각 exact 한 건을 preserve manifest로 기록하고 row 전체를 byte-identical하게 보존한다. HQ organization revision은 rewind/delete하지 않으며 모든 unrelated branch, office, command, effect, invitation, membership, fee, audit, receipt와 timestamp도 byte-identical해야 한다. cleanup 뒤 claim/email/branch-code/business-identity의 operational owner는 없어질 수 있지만 retained pair는 삭제 권위가 아니다.
DB-only acceptance는 네 registered delete RPC를 한 SQL transaction에서 실행한다. 각 첫 호출은 deleted_count=1, 같은 active/expired reference 재호출은 0이어야 한다. batch가 reaped가 되면 assembly reaper 재실행은 대상 batch 0의 no-op이고, stale direct reference 호출은 기존 exact 22023 stage test-data reference is not registered or reapable로 닫힌다.
실제 assembly reaper는 reference별 transaction과 5분 lease/updated_at CAS claim으로 수렴하는 resumable collector이며 batch 전체 원자 rollback을 주장하지 않는다. 기존 exact P01 manifest가 있으면 command가 이미 삭제된 부분 실행에서도 initial-only preparer를 다시 부르지 않는다. fresh empty manifest만 preparer를 호출한다. 첫 delete 전에 exact six-reference set을 preflight하고, 각 delete RPC 직후 같은 registered RPC를 재호출해 deleted_count=0을 확인하며 claimed revision으로만 reaped/failed status를 CAS한다. 이미 reaped인 concurrent winner를 loser가 failed로 되돌릴 수 없고, active lease 충돌은 reapedBatchCount가 아니라 별도 concurrentSkippedBatchCount로 보고한다. reaped batch/reference control-plane 기록은 retained cleanup audit이지 P01 business operational residue가 아니다.
p01_local deployment 직접 호출은 exact 42501 stage test-data reaper is disabled outside stage, 미등록/cross-target, owner 불일치, 미만료 reference는 저장 변화 없이 22023이어야 한다. malformed relation/column과 nonexistent public column도 기존 reaper의 typed error를 유지한다. public, anon, authenticated에는 EXECUTE나 protected table DML을 열지 않는다.
성공 뒤 command, journal, invitation, fee, office, office revision, core branch, membership의 target table 검색은 모두 0이다. scoped GET과 inspect도 zero rows이고 branch code, business identity, claim/email의 current operational lookup도 0이다. retained public audit 한 건과 private receipt 한 건만 이 zero-residue 계산에서 제외한다. 전체 fixture의 마지막 rollback은 별도 harness 위생이다.
첫 executable RED는 selected-migration clone에 existing stage reaper authority가 빠진 사실을 P01-DB-CLEANUP missing registered stage reaper authority로 고정한다. 그 뒤 cleanup corpus를 먼저 commit한다. 기존 historical reaper migration은 reservation add-option table과 결합돼 P01 최소 clone에 직접 replay할 수 없다. 따라서 새 범용 삭제 semantics를 만들지 않고 existing registry/guard/RPC를 idempotently materialize하는 dependency-free core reconciliation과 P01 전용 reference preparer만 추가한다. preparer는 service_role, materialized stage, exact batch/owner/source/TTL, completed command↔audit↔receipt parity를 검사한 뒤 위 manifest만 등록한다.
service_role은 batch/reference를 등록할 수 있는 trusted backend 운영 권위다. owner/TTL guard를 compromised service-role capability isolation으로 과장하지 않는다. anon/authenticated와 production deployment가 destructive boundary에 도달하지 못하는 것이 이 gate의 보안 주장이다.

DB13 cleanup GREEN 기록

Criteria assembly cd5eb5c와 경계 보강 c864f89 뒤 backend executable RED ee035d91이 exact P01-DB-CLEANUP missing registered stage reaper authority에서 멈췄다. 10-case cleanup corpus 911f248d를 먼저 고정하고, product d051b1ed6fdeecef675f9e12067b77fa95c4a810이 dependency-free reaper core reconciliation과 P01 manifest preparer를 추가했다.
Fresh selected-migration Supabase gate는 public schema lint [], DB13 10-case ledger, outer rollback, DB10 finalize, DB06 identity/email, DB11 repair, DB07 business-conflict races, source/clone/container/temp teardown을 통과하고 exact P01 branch onboarding durable-store local Supabase acceptance passed scope=full을 반환했다.
DB13은 네 operational reference의 첫 delete 1, immediate replay 0, target/search residue 0, active membership 0, retained public audit/private receipt exact pair, HQ/unrelated byte equality를 증명한다. 비-stage, 미등록, wrong-source/owner, 미만료, reaped reference는 fail-closed다. Branch-onboarding 및 reaper focused Python은 228 passed; Tach dependency/interface/external 진단은 0이다.
Assembly product 66ded57d6aaf3f83b8ccea9a529a1efb43f2d063은 실제 Node HTTP reaper 경로에 P01 preparer 결선, exact manifest, lease claim, partial-delete resume, RPC replay-zero, lineage-preserving status CAS와 truthful concurrent skip 집계를 구현했다. Mock PostgREST integration과 policy test는 10/10 통과했고 최종 독립 감사의 DB13 bounded blocker는 0이다.
이것은 DB13 DB+assembly 실행 계약 GREEN이다. 실제 stage P01 batch producer/actor run과 cleanup manifest는 아직 없고, Auth identity·SpiceDB relationship 삭제와 provider/Restate quiescence도 구현되지 않았다. 따라서 상위 P01-cleanup, P01 actor phase, screenshot/WebP는 계속 RED다. custom image build와 온라인 배포도 하지 않았다.

A14 Supabase durable-store adapter GREEN 기록

Backend 54974c2ba4d60db26f71b1313ee3070ff45deb98은 application durable-store port를 sanmopia_inspect_branch_onboarding_replay_or_resume, sanmopia_start_or_replay_branch_onboarding, sanmopia_record_branch_onboarding_side_effect_transition, sanmopia_finalize_branch_onboarding_accepted_and_current 네 RPC에 결선한다.
Typed RPC error RED/product bd910961/5cf91fa0, adapter RED 6cf149a9, 반례 corpus ed253f82/b0526eb8, product 7d13d0b4, UUID fixture hardening 54974c2b 순서다. PostgREST의 exact {code, details, hint, message}만 typed SQL error로 읽고, known SQLSTATE/message 조합만 business conflict 또는 internal CAS로 변환한다. 나머지는 dependency unavailable로 fail-closed한다.
Request, plan, prepared claim, transition, result는 명시적 closed camelCase serializer를 사용한다. Result의 relationships, effects, actions는 SQL과 같은 canonical 순서로 정규화한 뒤 exact 비교한다. 따라서 contract-valid order permutation은 first finalize와 replay 모두 성공하지만 다른 immutable fact drift는 숨기지 않는다.
Transition 응답은 scope와 expected revision + 1뿐 아니라 요청한 effect의 status/reference/failure와 canonical current candidate까지 일치해야 한다. 다른 effect를 전진시키거나 retry 시각을 바꾼 mock 응답은 거부된다. command ID의 선후행 whitespace와 U+FEFF는 application command 생성에서 RPC 전에 거부한다.
Adapter/command acceptance 79 passed, focused domain/application/adapter/platform 294 passed, Ruff, Tach dependency/interface/external이 통과했다. 최종 제품, test-corpus, layer 감사 blocker는 각각 0이다. Post-commit fresh Supabase CLI full gate도 public schema lint [], DB13 ledger, DB10/DB06/DB11/DB07 races, exact teardown 뒤 full-scope sentinel을 반환했다.
이 GREEN은 concrete adapter 제품과 DB 계약을 증명한다. 실제 process에서의 dependency construction, provider effect 실행/보상, Restate orchestration, HTTP interface, HQ actor run, screenshot/WebP는 아직 RED다. 따라서 P01 phase status는 계속 red다.

현재 gate 파일은 다음과 같다.

scripts/supabase_local_branch_onboarding_durable_store_smoke.sql
scripts/supabase_branch_onboarding_durable_store_fresh_test.sh
scripts/supabase_branch_onboarding_durable_store_race_test.sh
scripts/supabase_local_branch_onboarding_durable_store_race.sql
scripts/supabase_local_branch_onboarding_durable_store_race_worker.sql
scripts/supabase_branch_onboarding_repair_transition_race_test.sh
scripts/supabase_local_branch_onboarding_repair_transition_race.sql
scripts/supabase_local_branch_onboarding_repair_transition_race_worker.sql
scripts/supabase_branch_onboarding_business_conflict_race_test.sh
scripts/supabase_local_branch_onboarding_business_conflict_race.sql
scripts/supabase_local_branch_onboarding_business_conflict_race_worker.sql
supabase/migrations/20260715160000_branch_onboarding_durable_persistence.sql
supabase/migrations/20260716100000_stage_test_reaper_core_reconciliation.sql
assembly scripts/reap_test_data.mjs
assembly scripts/reap_test_data_policy.mjs
assembly scripts/reap_test_data_policy_test.mjs
assembly scripts/reap_test_data_integration_test.mjs

증거 승격 규칙

RED test revision, production revision, 전체 command output, disposable DB 식별자, table/RPC manifest, candidate-scoped partial-state count와 container teardown을 기록한다. UI와 actor phase가 열리기 전에는 screenshot이나 animated WebP를 만들지 않는다. 이후 실제 HQ actor run과 같은 four-repository revision에서 수집한 redaction-reviewed visual만 상위 P01 evidence로 승격한다.

최종 실제 actor·browser acceptance

P01 실제 Acceptance A-Z가 최종 절차와 시각 증거를 소유한다. 실제 HQ actor run은 P01 여섯 case를 모두 실행했다. 권한 거부 actor 3, validation variant 3, 직렬 conflict 4를 확인했다. 서로 다른 HQ의 branch-code와 business-identity 경합은 각 waiters=2, winner=1, typedLoser=1, partial=0이었다. exact replay는 같은 결과와 무변경을 반환했다. 세 accepted lineage cleanup 뒤 operational/Auth/SpiceDB relationship/actor session/temp HQ/ barrier 잔여는 모두 0, 보존 public audit와 private receipt는 각각 3이다.

실제 Astro build browser run은 route interception 없이 HttpOnly HQ session으로 UI submit, direct GET, same-origin exact replay 200, reload resume, stale conflict 무변경을 확인했다. browser·frontend process 잔여와 failed request/console error는 모두 0이다. desktop/mobile PNG와 4-frame real-transition.webp는 redaction review와 SHA-256 검증을 통과했다.

고정 revision은 assembly daec45376021c9df3fb7821c745e21766b32eae8, contract e4534e41c0cd9b06d6193e8850088469f798d162, backend f75548e76866ea10bf36c0f34824262850d0f8aa, frontend e429d59d31eadc046a2e1920ad29dc088fe15dba다. 증거는 docs/evidence/p01-branch-onboarding/과 canonical visual registry에 있다. 이 판정은 isolated local acceptance다. 온라인 배포나 전체 13-phase 완료를 뜻하지 않는다. P01은 PASS, P02는 RED다.