Mother And Family Conversational Booking Flow Source Map

This page maps the eleven input cards in the mother and family conversational booking flow. ready_to_submit is a terminal presentation state, not a twelfth business input. Sequential disclosure, answer transcript, current-card focus, and automatic scroll are deliberate frontend UX improvements. They have no legacy parity requirement and confer no booking, payment, or visibility authority.

This is discovery and migration evidence, not a new architecture decision. The accepted ADR corpus remains authoritative. Current evidence does not prove 100% booking parity: SFC-20260708-UX-001 is foundation. The canonical manifest now adds a current-pinned desktop submit-to-settlement result; mobile still proves the eleven-card UX without submission. Neither result proves family sponsorship grant/draft/acceptance binding.

Classification Summary

Card	Classification	Canonical target owner and term	Existing ledger linkage
`family_account`	New target capability	Member Management / `FamilyAccountAuthority`	SFC-20260711-FAM-001, SFC-20260711-FAM-007
`mother_profile`	Legacy-equivalent intent	Member Management + Reservation Operations / `ReservationPartyAuthoritySnapshot`, `ReservationBookerBeneficiarySnapshot`	SFC-20260711-FAM-001
`service_coverage`	Legacy-equivalent intent	Reservation Operations / `BranchServiceAreaPolicyDecision`	broad `BranchCoverageAddressFallbackRule` row; no new SFC id
`service_plan`	Legacy-equivalent intent	Reservation Operations + Service Calendar / `ServicePeriodPlan`, `ServiceDayOccurrence`	existing service-calendar rows; no new SFC id
`holiday_suspension`	Hybrid	Service Calendar / `HolidayPolicyExecutionAndImpactInvalidation`; Reservation Operations / `CustomerReservationIntent`	existing service-calendar and customer-intent rows; no new SFC id
`caregiver_preference`	Hybrid	Caregiver Assignment / `CustomerSmartMatchingPreferenceSnapshot`, `CandidatePreviewPolicy`	existing smart-matching row; no new SFC id
`reservation_sponsor`	New target capability	Member Management + Reservation Operations / `FamilySponsoredReservationDraft`, `SponsoredReservationContractAcceptance`	SFC-20260711-FAM-001
`payment_delegation`	New target capability	Member Management + Pricing Settlement / `PaymentDelegation`, `ReservationPaymentActorSnapshot`	SFC-20260711-FAM-002 through FAM-004, FAM-006
`pricing_support_payment`	Hybrid	Pricing Settlement / `IntakeQuotePreviewSnapshot`, `RegionalBenefitDecision`, `BookingPaymentMethodSelection`	SFC-20260706-UI-001, SFC-20260708-UX-001
`care_history_visibility`	New target capability	Member Management + Care Delivery / `ReservationCareHistoryAccessGrant`, `ReservationCareHistoryContentAuthorityDecision`	SFC-20260711-FAM-005 and FAM-007
`booking_details`	Legacy-equivalent intent	Reservation Operations / `ReservationIntakeDraftSession`, `ReservationBookingOperationalContext`	SFC-20260706-UI-001, SFC-20260708-UX-001

“Legacy-equivalent intent” means source behavior exists. It does not mean the current card value has proven field-level parity. “Hybrid” means one card combines source behavior with a new choice or new lifecycle concept. “New target capability” means the legacy system supplies a restrictive baseline or no equivalent authority model; target behavior is an approved improvement, not a legacy feature claim.

Existing machine-countable family rows remain in the 2026-07-11 family authority delta. This page links those ids and does not add duplicate ledger rows.

Exact 26-Catalog Legacy Authority Audit

The generated ADR-031 draft contract has 26 catalog bindings. The table below records their source authority as one auditable set instead of treating a contract key as proof that production data exists. service_addresses owns no option catalog; its separate authority is the final-review address snapshot plus BranchServiceAreaDecision described in card 3. Unless a path is fully qualified, controllers/, models/, and views/ below resolve under source-refs/sanmopia_web/application/; static/ resolves under source-refs/sanmopia_web/.

Draft step	Exact catalog keys	Legacy source authority	Required modern binding and current gap
`applicant_authority`	`applicant_authority.sponsorship_references` `applicant_authority.delegated_payment_references` `applicant_authority.eligible_extension_source_reservations`	Legacy permits only the mother to contract (`views/service/step1.php:70-75`). Extension eligibility is an owner-scoped database decision (`controllers/api/Reservation.php:258-286`, `models/Reservation_model.php:2052-2088`). Sponsorship and delegated payment have no legacy equivalent.	Backend `20c74e60` publishes sponsorship/delegation from revisioned ADR-021/ADR-020 capability facts. Backend `8e5465cc` publishes eligible extension sources from source-owned state/mapping revisions. All three browser selections are opaque; raw grant, delegation, and reservation ids remain internal authority lineage. Booking confirm must still consume and freeze those exact authorities.
`mother_contact`	`mother_contact.emergency_relationships`	PHP static codes `1=부`, `2=모`, `3=배우자`, `4=기타`, with free text for `4` (`views/service/step1.php:188-214`).	The relationship choice is contact intent, not sponsor authority. Backend `ba622266` freezes it against the exact catalog inside the accepted snapshot; contract `0f5f333` and backend `5be42194` expose the public-safe emergency contact in the 14-section final review while keeping catalog/authority lineage internal. Frontend `fb69309` renders and edits it from the final-review card.
`birth_and_babies`	`birth.delivery_types` `birth.baby_types` `birth.baby_genders` `birth.older_child_counts` `birth.care_center_terms`	Numeric ids and labels come from database lookup rows (`models/Constdata_model.php:71-115`, `:465-467`) and are conditionally rendered by birth state and baby type (`views/service/step2.php:90-517`).	Backend `ba622266` freezes the stable option keys, labels, baby sequence, gender, weight/name, and catalog/authority lineage. Contract `0f5f333` plus backend `5be42194` project the public-safe birth/baby facts without lineage leakage; malformed or non-contiguous babies fail closed. Frontend `fb69309` renders and edits the section.
`care_environment`	`care_environment.pet_species` `care_environment.pet_sizes`	The active row template hardcodes species and size codes (`views/service/smart_matching_1_table.php:21-36`, `:62-111`), while `models/Constdata_model.php:400-430` also loads pet lists from the database. Pet separation is a separate conditional boolean (`views/service/smart_matching_1.php:45-88`).	The source-reviewed catalog remains the SSOT instead of the PHP-static table. Backend `ba622266` freezes pet species/size/count and global separation semantics; contract `0f5f333` plus backend `5be42194` expose only the public-safe facts, and frontend `fb69309` renders and edits them. Pricing/operational consumers still must use their own named authority rather than infer policy from this display snapshot.
`service_offering`	`service_offering.offerings` `service_offering.voucher_delivery_rank_and_workforce` `service_offering.voucher_income_types`	Offerings and voucher axes are database and price-policy derived (`models/Constdata_model.php:123-316`) with birth, branch, date, service, and name/id filters (`controllers/Service.php:147-275`). The loader maps workbook delivery labels through mutable numeric lookup ids and handwritten aliases (`source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4997-5011`); the web model changes labels by baby/service ids, `id - 1`, and quadruplet switches (`source-refs/sanmopia_web/application/models/Constdata_model.php:258-291`). The retained workbook is `source-refs/sanmopia-admin/static/dist/excel/price/2026_voucher_260119.xlsx`.	Materialize branch/date/draft-scoped eligible offerings and all three voucher axes into `eligibleServicePlan`; frontend labels are not authority. `service_offering.offerings` has an exact producer registration and immutable source contribution. Backend `2882ae00` publishes `voucher_income_types` from one approved voucher-plan population, preserving its source position and actual `consume_type_value`; the guarded query rejects missing or ambiguous populations. Backend `f71170ef` publishes `voucher_delivery_rank_and_workforce` from that same approved population. Stable delivery codes feed one domain-owned rank/workforce presentation policy, so no numeric id or PHP switch enters the public option. The RPC requires one approved source revision and population, reindexes first source positions contiguously, and is service-role only; trusted preparation records the exact population fingerprint. Backend `cd57234f` replaces the voucher parser’s drifting positional P:W read with a named B:X workbook contract and known deletion-marker normalization. The pinned source commit is `437c43cb40f414b18091cfea8369c9334139424f`, SHA-256 `621a7667b326a3184bea2910b7fc49bbda553c93061d3f91af42d3cb70562a8c`; actual parsing is `ready_to_publish`, 198 entries, issue 0, four baby groups, and eight delivery codes. The registry is now 26/26 after the independently owned rental, service-priority, personality, regional-benefit support, and caregiver recommendation producers. Automatic create/PATCH refresh remains absent.
`service_schedule`	`service_schedule.durations` `service_schedule.work_schedules` `service_schedule.voucher_service_days`	Private duration/work choices come from database rows plus view filters (`models/Constdata_model.php:390-398`; `views/service/step3_normal.php:110-167`). Their current price source is also retained as `source-refs/sanmopia-admin/static/dist/excel/price/2026_normal_260119.xlsx`, loaded by `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4807-4981`. Voucher days are a deeper price-policy hierarchy: initial axes (`controllers/Service.php:318-369`), start-date refresh (`controllers/api/Service.php:889-925`), consume revision (`models/Reservation_model.php:3243-3258`), ordered slash tokens (`models/Constdata_model.php:155-316`), per-leaf price rows (`models/Reservation_model.php:1847-1883`), hierarchy/radio rendering (`views/service/step3_voucher.php:119-138`; `views/item/step3_item.php:1-44`), and browser cascade/reload (`static/js/step3_voucher.js:14-78`; `static/js/step3.js:563-581`, `:1149-1220`).	Private duration/work and voucher-day selections are mutually exclusive program axes. Backend `2c744fb` freezes the exact voucher-plan revision and source-token order, then maps it through named orchestration to `days_N` options. Backend `c1937ed` adds completed-source authority, atomic population, and committed-population exact selection; `b44fd49` makes the bridge resolve that selection from server-owned canonical criteria. Backend `7a9d26e` adds active-session HQ/SpiceDB approval, DB-owned time/manifest facts, approved-only RPCs, quarantine, and lineage guards. Backend `293fe13d` adds a dedicated private-care anti-corruption parser: stable tier/work codes, a normalized row model, declarative component rules, explicit five-service-day week policy, whole-KRW division, known deletion-marker normalization, and fail-closed unknown values replace PHP database-id lookups and mutable update branches. The pinned workbook SHA-256 is `ad3235e4f35108936c816046ec2da4522a3ff189c8c7b3f9a6443b79b07dd65b`; its source commit is `437c43cb40f414b18091cfea8369c9334139424f`. Actual parsing returns `ready_to_publish`, 20 entries, and zero issues across 3 tiers, 2 work arrangements, and 4 durations. This corrects the earlier “lookup rows absent” conclusion. Backend `f1868789` adds the immutable exact-batch source, one domain projection, and the `durations`/`work_schedules` contribution publishers. It derives 4 durations and 2 schedules from entry criteria rather than duplicating option rows; the five-service-day constant is domain-owned and reused by the workbook adapter. DB-owned publication time/fingerprint and published-row immutability replace caller-stamped status. The publishers are registered, but the actual 20-row workbook batch and automatic draft preparation are not yet published/executed.
`additional_services`	`additional_services.service_options` `additional_services.rental_options`	Availability depends on offering, baby type, work type, prior reservation, date, and generated calendar (`controllers/Service.php:333-470`). Option meanings/quantity ranges mix PHP rules with database price rows (`views/service/step3_normal.php:186-545`). Private-care option amounts also come from workbook columns H-P and the loader at `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4856-4865` and `:4917-4976`. Rental names/order come from `views/survey/a17_1.php:276-315`; live loading reads `LIST_RENTAL_TB` through `models/Constdata_model.php:380-387`; `views/service/step3_normal.php:190-240` adds one round-trip delivery charge when anything is selected and warns that breast-pump availability requires branch confirmation. `config/constants.php:109` fixes delivery at KRW 10,000. Admin billing uses KRW 15,000 equipment charge for the breast pump plus KRW 10,000 delivery, while the other four have no equipment charge (`source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:663-699`).	Publish allowed quantities/date bounds and freeze selected lines in plan and price projections. Backend `293fe13d` normalizes Saturday, holiday, hour, multiple-birth, and household add-on components from the pinned workbook. It makes the removed 2026 infant option explicit: blank or known deletion marker is accepted, while a reintroduced amount is blocked instead of silently discarded like the PHP assignment at line 4861. Derived triplet/quadruplet and weekly-to-service-day amounts live in named policy tables/functions with tests. Backend `f1868789` publishes 10 selectable service-option descriptors from the same immutable price batch fingerprint while keeping every KRW amount in the price-entry SSOT. Backend `816bc09f` adds one immutable, source-reviewed rental revision with five stable option keys in legacy survey order: health cushion, sitz bath, heat pack, breast pump, and bath thermometer. It replaces numeric live ids and duplicated UI/export branches with one Layer-first query and the existing domain `RentalEquipmentChargeCatalog`; reservation and settlement therefore consume the same equipment/delivery rates. Delivery aggregation is explicitly `reservation_level_max_once`, and only the breast pump requires branch confirmation. Catalog and exact source-anchor SHA-256 checks, service-role-only RPC access, immutable rows, and rollback-scoped DB smoke fail closed on drift. 용품명, 비목, 배송비, 장비료가 바뀌면 새 catalog revision과 evidence hash로 바꾸며 코드 상수로 박지 않는다. Backend `288e14a7`와 frontend `93b8c2e1`은 authenticated mother가 `health_cushion_rental`을 실제 선택해 Supabase draft, voucher quote `210,000원`, 장비료 `0원`, 예약 단위 배송비 `10,000원`, rental catalog/selection hash handoff와 desktop/mobile final review까지 도달함을 증명한다. Unknown, cross-offering, stale, duplicate, branch-unconfirmed key는 계속 fail-closed다. Confirmation-ready booking/payment와 service-balance·settlement·document의 동일 revision 소비는 남았다.
`caregiver_matching`	`caregiver_matching.religions` `caregiver_matching.priorities` `caregiver_matching.personalities` `caregiver_matching.recommendations`	Preference lists are database-derived (`models/Constdata_model.php:400-462`). Priority UI repeats three selects and removes already chosen rows (`views/service/smart_matching_1.php:126-174`); the survey fixes exact source codes and labels to `0=산모케어`, `1=신생아케어`, `2=음식 등 가사분야` (`views/survey/smart_matching_1.php:225-270`). Submission deletes and sequentially reinserts three ranks (`controllers/api/Service.php:630-637`, `models/Smart_matching_model.php:205-228`). Personality authority is six hardcoded pairs in `views/survey/a25.php:58-210`, while `models/Constdata_model.php:433-461` orders numeric database rows and blindly groups each two rows. `views/service/smart_matching_2.php:45-135` and `static/js/smart_matching_2.js:1-57` render and require all six answers; `controllers/api/Service.php:643-671` plus `models/Smart_matching_model.php:238-267` transactionally replace numeric-id answers. Recommendations are matching/database results (`controllers/Service.php:598-623`), but legacy review also defaults a hidden manager id and rewrites it in JavaScript (`views/service/reservation_check_data.php:147-219`, `static/js/reservation_check_data.js:3-21`).	Preferences remain intent. Backend `d4b8e467` publishes `priorities` from one immutable, source-reviewed revision. Stable keys `postpartum_care`, `newborn_care`, and `household_care` replace public numeric codes; one domain `ordered_unique`/maximum-three policy validates order and creates the existing `CaregiverServicePreference` matching inputs. Backend `87e63f27` publishes `personalities` as six source-ordered pairs and twelve stable `question.answer` keys. One domain catalog enforces the six-by-two shape and exactly one answer per question, translates it into existing `CaregiverPersonalityAnswer` inputs, and records four source typo/spacing normalizations in the fingerprint. Backend `a325e02f` publishes `recommendations` from the existing frozen `CaregiverCandidateRecommendationSet` decision authority. Raw `MANAGER_ID_PK`, candidate profile id, and snapshot id are not browser option values; browser receives opaque `selectionReference`, while internal selection authority preserves the source recommendation set and snapshot revision. Current final review still needs automatic exact-set refresh and retained preference/recommendation display before PASS.
`contract_and_payment_preference`	`contract_and_payment_preference.payment_methods` `contract_and_payment_preference.support_programs` `contract_and_payment_preference.promotion_entitlements`	Active legacy payment codes are `CARD` and `VCNT`; `BANK` is commented (`views/service/reservation_payment.php:128-132`). Support is address/price-version conditional (`views/service/step3_voucher.php:140-223`). Promotions are owner-specific eligible coupon rows (`controllers/Service.php:638-649`). Legacy payment review sums multiple coupon rows (`models/Reservation_model.php:1200-1205`; `views/service/pre_reservation_payment.php:123-127`) and floors customer payable at zero (`models/Reservation_model.php:1261-1262`; `views/modal/modal_change_payment.php:5-13`).	Payment preparation, support/discount decisions, quote, and charge snapshot are backend facts. `bank` cannot claim legacy parity merely because the new contract permits it. Backend `1fd9cdda` publishes the authenticated owner’s current `issued`/`restored` reservation-discount entitlements, binds exact rule/entitlement revisions, emits only a hashed browser reference, caps authority expiry to entitlement expiry, and revokes frozen authority after relevant mutation, redemption, or deletion. Backend `867ba51f` revalidates the frozen selection against that live owner revision, applies multiple coupons in catalog source order, caps them at reviewed payable, and propagates one adjusted amount through quote, charge handoff, payment preparation, and waiting-obligation input; raw authority ids and browser order are not pricing authority. Backend `adeae516` publishes `support_programs` from the regional-benefit SSOT. The legacy 완주군 branch is preserved as source evidence but not copied as address-string/DOM/price-version code; region code and price-version windows live on `RegionalBenefitRule`. 영등포구 is recorded as removed on 2023-02-01, so current v4+ authority is a reviewed empty catalog. Backend `8e37ab8a` revalidates a future selected non-empty option against that exact catalog fingerprint plus preparation region/branch/price-version, then evaluates only pricing-domain fixed/rate/component formulas against backend quote components. Backend `8b214509` freezes the complete accepted discount-only decision in an internal mapping, exact-validates it through a reservation-booking application contract, and passes it to the booking command. Backend `4f1eea71` makes `supportAndDiscountDecisions` an explicit final-review missing fact and derives booking/payment/contract blocker codes from the unresolved fact set instead of a static tuple. An all-technical-authority test leaves only `serviceContract.acceptance`; frontend `1c7bd8b2` renders the four server-owned blocker codes as exact Korean copy. Browser amount input remains impossible. Service-day/end-date/own-price effects still fail closed, and real non-empty Supabase outbox→booking→settlement proof remains open. A proven empty catalog is valid.

Backend 558510d now consumes the exact 26-key set through one actor/draft-scoped materialized snapshot. The adapter imposes an internal canonical order for fingerprinting and rejects missing, duplicate, malformed, stale, or fingerprint-mismatched data. Contract clients must not infer semantic ordering from the catalog array. The adapter does not produce the rows. Backend 1200f42 adds the consumer-owned immutable contribution facade and inbox, an exact 26-binding registry, and the first registered source owner: service_offering.offerings to reservation_operations.service_offering_availability. The source command requires real title/version metadata and matching policy revision lineage. It is deliberately not wired to the public decision-set request, because a trusted orchestration must first resolve the exact draft, branch, pricing, and birth facts. One contribution is not a materialized snapshot: the exact-26 consumer continues to fail closed. The remaining 25 producers, exact-26 atomic materializer, and explicit final-review bindings for emergency contact, birth/baby facts, pets, caregiver preference answers, and selected promotion entitlement remain required before field-level parity can be claimed. Backend 83ac5b8 preserves contribution authority reference/revision facts, uses one owner/draft/revision scope lock, and makes the materialized snapshot tables read-only to service_role; a privileged RPC must own future writes. The legacy contribution overload remains as a database-first rollout wrapper for the current non-revision producer. These are materializer prerequisites, not another source producer or a readable exact-26 snapshot. Future materialization must persist exact contribution-set lineage, and the loader must reject a snapshot as soon as that lineage differs from the current latest 26 contributions. Backend 2c744fb adds the second producer boundary, service_schedule.voucher_service_days, backed by an immutable normalized voucher-plan revision. Legacy SERVICE_DAY_LIST slash-token position is the only service-day order: the source query has no ORDER BY, and workbook row_number is unrelated provenance. The reader therefore requires exact revision selection and an ordered one-to-one option/price-line mapping; it never infers latest/current rows. Blank or incomplete price lineage fails closed. One legacy inconsistency is intentional: a single option is always classified standard, instead of reproducing the first-row shortened label. At backend 2c744fb, producer registration and production composition existed, but a trusted trigger and authority population were absent. That increment left 24 producer boundaries, exact-26 materialization, and final-review materialization open.

Backend c1937ed198005ce2307dfefc4e77d882aa98abc0 adds the next Pricing Settlement authority boundary without rewriting that historical 2c744fb state. A completed source revision owns ordered raw SERVICE_DAY_LIST slices independently from the published price batch. The population command binds service_type_detail_code to service_tier_code, baby_type_code to criterion child_group, delivery_count_code to criterion delivery_order, explicit benefit_band_code to criterion benefit_band, and each day token to service_day_count; it never infers these facts from a consume_type_ prefix. One transaction validates full price-entry coverage, publishes every derived voucher-plan revision, records one deterministic population receipt, and links the revisions to that committed population. Selection then resolves exactly one committed revision from canonical pricing axes plus quote date. A caller cannot nominate catalog revision, import batch, price version, or consume-type revision keys, and no latest fallback exists. Backend b44fd49e9f3082d4affa005ecfa76128136f0804 binds that exact decision port into the reservation voucher-day bridge and rejects decision drift before revision read. It does not invoke the bridge from create or PATCH. Backend 7a9d26e1c1c53b928e14504cfd37152294f9a31f adds the trusted HQ caller: active bearer session actor plus SpiceDB manage on hq_settlement:price_catalog_management, DB-owned first approval stamp/replay, and canonical manifest SHA-256 over the frozen header, ordered slices, batch/workbook, and normalized entries. Caller actor/time/manifest injection is rejected; workbook, catalog/version, and entry equality must be exact. Only approved completion/publication RPCs remain executable to service role. Existing unapproved populations are preserved but quarantined, with immutability, insert, and deferred linkage guards. No real source/version was selected, approved, or invoked, and 154 / 0 is not an automatic choice. No draft prepare trigger invokes the selector or producer. The remaining 24 producer boundaries, exact-26 materialization, and final-review materialization stay open.

Backend 20a79e30e36c6693002c65f8211275afbe149310 closes the exact-set materializer implementation gap only. It adds MaterializeCustomerReservationStepOptionCatalogSnapshotHandler, strict Supabase current-set source and CAS sink adapters, runtime composition, and migration 20260715090000_customer_reservation_step_catalog_exact_set_materializer.sql. The database ranks the newest contribution for each canonical binding, requires the exact current 26, rechecks the caller’s ordered lineage, payload, time window, and two fingerprints under the same scope lock, freezes 26 lineage rows, and serves the snapshot only while that lineage still matches the current set. Focused application/adapter/runtime verification reports 193 passed; a narrower integrated run reports 38 passed, with Ruff and git diff --check passing. Migration/SSOT contracts report 14 passed; the rollback-scoped isolated Supabase PostgreSQL 17 smoke proves exact-25 failure, exact-26 atomic write/replay, stale and lineageless rejection, invalid/expired latest-row no-fallback, cross-time-zone and canonical hashes, and RPC-only ACL. This is pinned backend evidence, not full-history reset or stage proof. No trusted draft prepare or PATCH trigger calls it, only two producers exist, and no source has populated a complete set. No UI, browser, stage, screenshot, or WebP evidence was created or reused.

Backend 863158c743e2bc48e3db1dbb1a1f9d65edb0892d stages the next consumer-owned boundary without changing that completion claim. A service-role RPC can record and load one exact draft-revision catalog-preparation projection with 17 axes, a canonical fingerprint and projection id, monotonic revision, and at most a 15-minute validity window. The application adapter independently recomputes both hashes and fails closed on scope, draft, time, payload, or newest row drift. Service-offering reads now collapse duplicate global/region/branch rows with combined branch-and-region, branch, region, then global precedence and latest effective date inside the winning scope. A dormant named orchestration preserves this projection in the two existing producer lineages and then asks the exact-26 materializer to enforce completeness. No source-owned resolver or recording caller derives the 17 axes, 24 producer boundaries and refresh are still absent, and there is no HTTP, PATCH, queue, trigger, enqueue, or worker activation. Disposable PostgreSQL apply/reapply, replay 1 -> 1, renewal to revision 2, six negative fail-closed cases, ACL, and zero queue/trigger objects passed; the temporary database was removed. This backend-only increment added no deployment, browser execution, screenshot, or WebP.

17-Axis Preparation Source-Lineage Audit

Backend 59d29eb79359018f116c0be941c6d1a288e44e5c, after smoke cleanup 406d56565eae8ff51a7ec354a1c68aadb11db90c, translates legacy vocabulary once before serializing the existing 17-key compatibility payload. The mapping below records semantic authority; a PHP field name is evidence, not a modern contract name.

Modern meaning	Legacy authority and conflict	Required binding and current state
Canonical branch profile and source branch id	Address lookup and impossible-area veto select the legacy branch before `RESERVATION_TB.BRANCH_ID_FK` is stored (`source-refs/sanmopia_web/application/views/service/step1.php:108-140`, `source-refs/sanmopia_web/application/controllers/api/Service.php:35-59`, `source-refs/sanmopia_web/application/models/Branch_model.php:45-140`, `source-refs/sanmopia_web/application/models/Reservation_model.php:325-339`).	`branch_profile_id` is the modern opaque identity; `source_branch_id` preserves legacy compatibility. `branch_coverage` lineage must reference the exact branch profile.
Current pre-reservation state	Availability checks status `15`; `PRERESERVATION_FL=1` instead records a historical pre-reservation attempt/conversion (`source-refs/sanmopia_web/application/models/Reservation_model.php:2895-2914`, `source-refs/sanmopia_web/application/models/Payment_model.php:101-123`, `:737-752`).	`is_currently_pre_reserved` comes from `reservation_state`. Historical conversion must never be mapped into current availability.
Birth state and calendar distance	`BIRTH_FL` persists expected versus completed birth while `BIRTH_DT` stores the applicable date (`source-refs/sanmopia_web/application/views/service/step2_before.php:40-47`, `source-refs/sanmopia_web/application/views/service/step2.php:53-70`, `source-refs/sanmopia_web/application/models/Reservation_model.php:403-418`).	Draft derivation produces `birth_occurred` and `calendar_days_until_expected_birth` against the Asia/Seoul business date; it does not infer persisted state from the date sign.
Actual baby count and voucher baby classification	Delivery rows preserve up to four baby-gender positions, while voucher price lookup uses a separate `BABY_TYPE_LIST_ID_FK` classification (`source-refs/sanmopia_web/application/models/Reservation_model.php:403-418`, `:3140-3147`, `:3225-3239`). Legacy in-home exclusion reads that voucher classification, not a counted baby list (`source-refs/sanmopia_web/application/views/service/step3_selecttype.php:80-93`).	`actual_baby_count` and `voucher_baby_classification_code` are independent. Missing voucher classification fails voucher in-home availability closed.
Source price version identity	Service type plus desired start date selects and stores `PRICE_VERSION_LIST_ID_FK` (`source-refs/sanmopia_web/application/controllers/api/Service.php:146-150`, `:257-260`, `:299-304`, `source-refs/sanmopia_web/application/models/Reservation_model.php:3149-3166`).	`source_price_version_id` is an owner decision; it is not a year or ordinal `version_number`.
Continuation request and server-linked continuation	The server creates a new reservation and links it through `RESERVATION_CONTINUE_TB`; later checks read that link (`source-refs/sanmopia_web/application/controllers/api/Reservation.php:243-286`, `source-refs/sanmopia_web/application/models/Reservation_model.php:2092-2112`, `:2215-2229`, `:2430-2437`).	Draft `continuation_requested` is intent only. `is_server_linked_continuation` comes from `reservation_state`, and disagreement fails closed.
Inclusive pre-reservation day policy	Legacy computes “40 days” as today plus 39 days and includes that boundary (`source-refs/sanmopia_web/application/controllers/Service.php:196-208`, `source-refs/sanmopia_web/application/views/service/step3_selecttype.php:58-86`).	`pre_reservation_minimum_inclusive_day_number` counts today as day one; a 39-day date difference satisfies the 40-day rule.
Birth method versus voucher delivery rank/workforce	Step 2 `delivery_type` means birth method (`source-refs/sanmopia_web/application/views/service/step2.php:90-100`). Voucher `delivery_type` instead stores birth rank or, for multiple births, workforce (`source-refs/sanmopia_web/application/models/Constdata_model.php:155-182`, `:258-313`, `source-refs/sanmopia_web/application/models/Reservation_model.php:488-503`).	Use separate birth-method and `voucher_delivery_rank_and_workforce_option_key` terms. The option carries a stable `deliveryCountCode`, domain-derived `deliveryRankLabel`, and optional `workforceCount`; legacy numeric ids never cross the adapter. `voucher_consume_type_key` must come from the same approved canonical voucher-plan population, never field-name coincidence or prefix inference.
Modern catalog metadata and business clock	No direct legacy authority exists for modern `catalog_id`, normalized `region_code`, `evaluated_on`, service-offering policy revision, or `quoted_on`. PHP uses process-local current dates and mutable lookup state.	Policy owners supply identity and revision lineage. PostgreSQL requires `evaluated_on == quoted_on == statement_timestamp()` in Asia/Seoul and expires the record before the next Seoul midnight.

The v2 envelope freezes exactly five lineage entries: branch_coverage, reservation_state, service_offering_policy, price_catalog_version, and voucher_plan_criteria. Each entry has exactly owner_context, source_reference, source_revision, source_fingerprint, valid_from, and valid_until; payload and lineage share one SHA-256 projection identity. Offering publication now requires this preparation-authority catalog lineage. Public availability endpoints remain non-authoritative previews, and booking still accepts a caller-provided availability decision; it must rehydrate the exact server projection before activation. Concrete source adapters are 0/5, record-handler runtime wiring is 0, runtime E2E axes are 0/17, and activation surfaces are 0. Therefore this is backend foundation, not source resolution or booking parity. No deployment, stage, browser, screenshot, or WebP was produced.

Step-By-Step Source Mapping

1. `family_account`

Source anchor: source-refs/sanmopia_web/application/views/service/step1.php:74-93 says only the mother can contract. Lines 193-209 collect a spouse or family emergency contact only. source-refs/sanmopia_web/application/controllers/api/Service.php:18-59 loads the logged-in user and inserts the draft against that user’s id. source-refs/sanmopia_web/application/models/Reservation_model.php:320-370 persists USER_ID_FK and updates that same profile.
Preserve: authenticated mother ownership and emergency-contact facts. A relation label or phone number stays contact evidence and grants nothing.
Deliberate improvement: a revisioned family account can expose approved members without pretending the legacy spouse contact was a sponsor or payer.
Target binding: Member Management returns a backend FamilyAuthorityDirectoryView. Frontend renders member display facts and opaque ids only; it must not normalize “남편” or “보호자” text into authority.
Open gap: current card role choices alone do not prove active membership, sponsorship, payment delegation, or care-history access. Bind the card to the backend directory query and inactive/revoked-member result. Ledger: SFC-20260711-FAM-001 and SFC-20260711-FAM-007.

2. `mother_profile`

Source anchor: source-refs/sanmopia_web/application/views/service/step1.php:90-100 renders name and birth from the logged-in profile; lines 188-219 collect reservation phone, emergency phone, relation, and email. source-refs/sanmopia_web/application/controllers/api/Service.php:56-83 writes reservation-time contact facts and also mutates profile contact facts.
Preserve: mother name, birth, reservation contact, emergency contact, and email as distinct facts tied to the authenticated booking subject.
Deliberate improvement: freeze ReservationBookerBeneficiarySnapshot and ReservationPartyAuthoritySnapshot; do not let booking edits silently rewrite mutable profile truth or convert emergency contact into consent authority.
Target binding: Member Management owns profile and party authority; Reservation Operations consumes the frozen beneficiary snapshot.
Open gap: a free-text or locally defaulted motherId is not verified identity. Operational context must return the exact mother projection, profile revision, editable fields, disabled reason, and self-versus-sponsored booking path. Ledger: SFC-20260711-FAM-001.

3. `service_coverage`

Source anchor: source-refs/sanmopia_web/application/views/service/step1.php:103-187 separates home, service, and optional second service address. source-refs/sanmopia_web/application/controllers/api/Service.php:35-100 resolves branch coverage, returns not_support, marks consultation for a consultation area or second address, geocodes, and persists address rows. source-refs/sanmopia_web/application/models/Branch_model.php:45-140 checks exact, parent, city-wide, and split composite-address matches, then vetoes the match when a corresponding 불가 rule exists.
Preserve: multi-address distinction, ordered fallback matching, impossible-area veto, consultation routing, canonical branch, and geocoding evidence.
Deliberate improvement: BranchServiceAreaPolicyDecision freezes lookup keys, matched depth, veto evidence, policy version, and canonical branch.
Target binding: Reservation Operations owns the decision. Frontend sends address intent through a typed contract and renders backend serviceability; regionHint never selects a branch.
Open gap: first-period, second-period, extension, and continuation booking workflows still need the same frozen decision before pricing, matching, and transfer. Pipe-delimited address|region|note parsing is presentation draft data, not a contract. Reuse the existing BranchCoverageAddressFallbackRule checklist row; do not mint a duplicate SFC id.

4. `service_plan`

Source anchor: source-refs/sanmopia_web/application/controllers/api/Service.php:146-190 records delivery and baby facts and selects price version from expected start date. Lines 198-266 select voucher/private service and change the route. Lines 302-335 enforce start after birth and voucher constraints. source-refs/sanmopia_web/application/models/Reservation_model.php:463-520 calculates different voucher-day and private-week periods.
Preserve: service kind/detail, voucher versus private duration semantics, birth/start constraint, expected start, price-policy version, and continuation eligibility.
Deliberate improvement: backend ServicePeriodPlan and ServiceDayOccurrence replace browser/PHP end-date branches and preserve the policy revision used for the quote and booking.
Target binding: Reservation Operations owns plan intent; Service Calendar owns executable occurrences. Eligible plans arrive as backend catalog choices, not hardcoded one-, two-, or three-week labels.
Open gap: backend 2c744fb can project voucher service-day choices from one exact published voucher-plan revision, backend c1937ed now provides completed-source authority, atomic population, and committed-population exact selection, and backend b44fd49 resolves the internal bridge selection from canonical criteria rather than caller-owned revision keys. Backend 7a9d26e adds the HQ-authorized, DB-canonical approved completion path. The current backend 20a79e3 adds the exact-26 handler, Supabase runtime composition, same-set CAS, frozen lineage, and current-set loader gate. No real source has been selected, approved, or invoked, no draft prepare trigger invokes the selector, producers, or materializer, and the missing 24 producers prevent a complete snapshot. Working type, multiple-birth impact, continuation, and cross-step policy effective date still need one plan projection. backend_context is a fail-closed placeholder, not a selected plan. Reuse existing service-period/calendar rows.

5. `holiday_suspension`

Source anchor: source-refs/sanmopia_web/application/views/service/step3_normal.php:251-330 and source-refs/sanmopia_web/application/views/service/step3_voucher.php:323-395 collect exact paid Saturday and holiday dates. Their summary warnings at step3_normal.php:547-564 and step3_voucher.php:622-640 say holidays are closed by default. source-refs/sanmopia_web/application/controllers/api/Service.php:367-414 and :476-521 persist selected dates, charge option quantities, and end-date effects. Later service stop is a different lifecycle: source-refs/sanmopia_web/application/controllers/api/Reservation.php:86-204.
Preserve: exact weekend/holiday selections, default closure, charge impact, service-calendar impact, and later stop-request semantics.
Deliberate improvement: one frozen HolidayPolicyExecutionAndImpactInvalidation feeds quote, matching, report, refund, and settlement. A stop/suspension uses a separate revisioned CustomerReservationIntent command.
Target binding: Service Calendar owns holiday execution. Reservation Operations owns later suspension/stop intent. Frontend may collect a preference but may not convert it into calendar facts or a lifecycle command.
Open gap: current combined labels (weekend_available, holiday_excluded, suspension_review) conflate three different meanings. Split calendar preview from later suspension intent; require exact date, reason, expected revision, and backend availability before mutation.

6. `caregiver_preference`

Source anchor: source-refs/sanmopia_web/application/views/service/smart_matching_1.php:70-165 collects pet separation, religion, and three ranked care priorities. source-refs/sanmopia_web/application/views/service/smart_matching_2.php:70-152 collects paired personality answers and free-text sensitivity notes. source-refs/sanmopia_web/application/controllers/api/Service.php:592-635 replaces preference rows, while lines 765-810 allow a direct caregiver pick and delete prior matching facts.
Preserve: pet/religion compatibility, ranked care priorities, personality choices, free-text care instruction, named-caregiver intent, and candidate explanation.
Deliberate improvement: append-only CustomerSmartMatchingPreferenceSnapshot, deterministic CandidatePreviewPolicy, and explicit CaregiverPickOverrideCommand replace silent preference deletion and opaque candidate selection.
Target binding: Caregiver Assignment owns matching facts and candidates; Care Delivery owns caregiver-visible instruction masking. Frontend renders a backend option catalog and candidate reasons.
Open gap: backend d4b8e467 field-maps the three ranked care priorities, and backend 87e63f27 maps all six personality pairs, to immutable catalogs that preserve source order and create existing matching inputs. Free-text sensitivity and named caregiver intent still need field-level evidence and final-review retention. The actual recommendation decision remains a separate source-owned producer. Product must map each retained source fact or record an approved de-scope decision. Reuse the existing customer smart-matching checklist row.

7. `reservation_sponsor`

Source anchor: the mother-only rule is explicit at source-refs/sanmopia_web/application/views/service/step1.php:74-93. Spouse/family fields at :193-209 are emergency contact only. The controller binds creation to the logged-in user at source-refs/sanmopia_web/application/controllers/api/Service.php:18-59.
Preserve: mother retains contracting authority. Family preparation must never make emergency-contact relation text authoritative.
Deliberate improvement: accepted ADR-021 adds revisioned sponsorship, sponsor-authored draft, immutable mother acceptance/decline, contract version, fingerprint, one-time consumption, and revocation.
Target binding: Member Management owns sponsorship and acceptance; Reservation Operations consumes accepted authority at booking start.
Open gap: local canBookForMother derived from “허용/불가” cannot grant or deny sponsorship. The card must render active grant/draft/acceptance projections and submit only intent plus expected revision. Ledger: SFC-20260711-FAM-001 is runtime_wired, not migrated.

8. `payment_delegation`

Source anchor: legacy routes require the reservation owner for deposit at source-refs/sanmopia_web/application/controllers/api/Payment.php:89-113, balance at :325-372, pre-reservation payment at :523-545, and payment change at :681-709. These are separate payment purposes; none defines family delegation.
Preserve: exact reservation ownership baseline, distinct payment purpose, current unpaid obligation, provider method eligibility, and frozen amount.
Deliberate improvement: PaymentDelegation adds reservation, purpose scope, positive amount ceiling, effective interval, revision, revocation, and immutable ReservationPaymentActorSnapshot evidence.
Target binding: Member Management owns grant lifecycle; Pricing Settlement authorizes and freezes one obligation before provider handoff.
Open gap: authorized, limited, or blocked selected in NanoStores is not authority. The UI must query current delegation and amount scope, then submit paymentId through backend pre-registration. Remaining live proof includes balance, pre-reservation conversion, change adjustment, expiry, ceiling denial, provider callback, receipt, and refund visibility. Ledger: SFC-20260711-FAM-002 through FAM-004, plus FAM-006.

9. `pricing_support_payment`

Source anchor: the final confirmation renders mother, address, service, period, add-ons, backend-loaded fee table, coupons, and consultation state at source-refs/sanmopia_web/application/views/service/reservation_check_data.php:1-101 and :210-340. Deposit uses live PRICE_TABLE and owner/payment state at source-refs/sanmopia_web/application/controllers/api/Payment.php:89-113. Region, support, weekend, holiday, coupon, and service-balance branches are inventoried in the existing charge and regional-benefit checklist rows.
Preserve: service price, government/regional support, customer share, coupon/discount, deposit/balance purpose, eligible payment methods, and the exact frozen quote used for booking.
Deliberate improvement: backend IntakeQuotePreviewSnapshot, RegionalBenefitDecision, ReservationChargeLineCatalogProjection, and BookingPaymentMethodSelection replace browser price maps and label-driven policy.
Target binding: Pricing Settlement owns amount, support, discount, payment purpose, method eligibility, and revisions. Frontend owns formatting and a review/request preference only.
Open gap: selected voucher_support amount authority is implemented at backend 8e37ab8a; backend 8b214509 also freezes the complete accepted discount-only decision and passes it through a consumer-owned application contract into the booking command. Real non-empty Supabase outbox→booking→ settlement/document proof and service-day/end-date/own-price effects remain. Selected coupon review now revalidates live owner revision, applies multiple coupons in source order with a zero-payable floor, and feeds the same quote/payment amount. family_payment_review or balance_later cannot change eligibility or price. Bind them to a frozen quote and payment-method projection; prove all regional-benefit, coupon, zero-amount, deposit/balance, refund, and settlement consumers use the same snapshot. Ledger: SFC-20260706-UI-001 and SFC-20260708-UX-001 remain below end-to-end parity.

10. `care_history_visibility`

Source anchor: legacy reservation lists and details are owner-scoped at source-refs/sanmopia_web/application/controllers/MyReservation.php:22-48, :73-98, and :117-175. Mother report access rejects non-owner bookings at :193-222. Caregivers create report content through their own reservation check at source-refs/sanmopia-manager/application/controllers/Report.php:21-87 and report definitions at source-refs/sanmopia-manager/application/models/Report_model.php:44-67.
Preserve: mother access to her booking and report content, caregiver authorship boundary, and separate review/rating mutation authority.
Deliberate improvement: accepted ADR-024 adds exact booking-scoped family read grants, privacy-safe content projection, opaque pagination, non-enumerating denial, and separate mother-only review mutation.
Target binding: Member Management owns ReservationCareHistoryAccessGrant; Care Delivery owns GetReservationCareHistoryQuery and render-ready content.
Open gap: a local “예약만/요약/관리 이력” selection cannot grant access or predict what the mother can later view. Treat it as a grant/request intent, execute backend CQRS, then render returned visibility. SFC-20260711-FAM-005 proves the read path end to end; it does not prove this conversational card is bound to that path.

11. `booking_details`

Source anchor: final source confirmation selects consultation versus booking, shows matched-caregiver caveats, and asks for final confirmation at source-refs/sanmopia_web/application/views/service/reservation_check_data.php:1-55. Lines 210-340 summarize customer, all addresses, service type, working type, period, exact dates, add-ons, fee table, and coupons. Contract consent, signature, and eligible payment method follow at source-refs/sanmopia_web/application/views/service/reservation_payment.php:42-145.
Preserve: complete review before financially binding progression, consultation route, plan/quote snapshot, contract version and acceptance, and backend-selected payment handoff.
Deliberate improvement: ReservationIntakeDraftSession keeps sensitive state server-side with revision, expiration, per-step validation, explicit discard/submit, and source/catalog evidence. ReservationBookingOperationalContext supplies backend-owned final values.
Target binding: Reservation Operations owns draft and workflow command; Pricing Settlement owns charge/payment projections. Frontend submits typed intent through the approved booking client.
Open gap: schedule|serviceType string splitting omits delivery/baby, service detail, duration, exact dates, add-ons, rentals, preferences, quote, contract, and expected revisions. Replace it with generated contract fields and a backend review projection. SFC-20260708-UX-001 proves card interaction, not current full submit/payment parity.

Cross-Step Binding Gate

Each card advances only presentation state. Before any card can be called migrated, evidence must prove:

card choices come from a typed backend projection or are explicitly marked non-authoritative draft intent;
no display label, pipe-delimited string, phone, relation text, local boolean, role string, amount, method, region hint, or default grants authority;
every command rechecks authenticated actor, capability, expected revision, policy/catalog version, and idempotency;
edits invalidate later cards whose backend projection changed;
final review shows the same frozen party, coverage, plan, calendar, matching, quote, sponsor, payer, and visibility facts consumed by booking;
desktop and mobile browser runs submit, reach backend workflow progress, exercise payment handoff where required, and record zero console/network errors and zero leaked browser processes; and
source checklist status advances only when its declared persistence, contract, runtime, and legacy-authority removal evidence exists.

ADR Lineage And Conflicts

ADR-012 is accepted and partial. It permits NanoStores for ephemeral input/disclosure only. Local derivation of sponsor permission, delegation status, mother visibility, service/calendar policy, or quote eligibility conflicts with its decision.
ADR-018 is accepted and partial. Browser cards cannot carry allowed, role, capability, or actor booleans as authorization evidence. Backend be107c7 now removes all authenticated privileges and participant policies from the reservation booking and workflow-request tables, including raw workflow command_payload reads. Customer progress and draft recovery must therefore use typed backend queries rather than restoring Data API access.
ADR-020 is accepted and partial. payment_delegation must use backend obligation and actor-snapshot rules, not locally selected delegation state.
ADR-021 is accepted and partial. family_account and reservation_sponsor must use revisioned grant, draft, mother acceptance, and one-time consumption.
ADR-024 is accepted and implemented for its declared read-model scope. It does not make the conversational visibility choice authoritative.
ADR-028 is accepted and partial. It governs self-booking submitter separation but does not prove every browser/runtime variant. Keep self-booking scoped separately from ADR-021 family sponsorship; do not use ADR-028 to bypass accepted family, payment, calendar, pricing, or visibility decisions.
ADR-031 is accepted and partial. It governs the server-owned draft, final_review authority projection, and idempotent customer reservation creation command. Contract 8ce891f is installable and backend b44fd49 mounts all five typed routes with authenticated mother, durable persistence, exact projection-backed catalog/final-review adapters, and two source-owned producer boundaries. Pricing Settlement now also owns completed voucher-plan source revisions, atomic population receipts, and committed-population exact selection. Backend 7a9d26e adds the protected HQ approval caller, but no real source/version has been selected, approved, or invoked. Backend 20a79e3 adds the exact-26 handler, Supabase source/sink composition, same-set CAS, frozen lineage, and stale-lineage loader gate. Backend 59d29eb adds typed draft derivation, five preparation source contracts, the record handler, v2 source-lineage persistence, and database-owned Asia/Seoul time without runtime activation. Backend 68ce17dc completes concrete source composition 5/5, and backend 0934462d adds v3 split-date persistence plus terminal record→publish→reload runtime wiring. Runtime E2E axes remain 0/17, and actual Supabase actor activation remains unproved. Public availability results are previews; booking must rehydrate the server projection instead of trusting its caller-provided decision. Final-review materializers and the atomic ADR-020 handoff remain open. UI card, isolated migration, and in-process HTTP evidence do not prove full-history PostgreSQL or stage runtime parity.

No new ADR is required merely for one-question disclosure or automatic scroll. ADR-031 governs the current draft/review/creation boundary. A new accepted ADR is required before changing authority, ownership, compatibility, or the accepted meaning of sponsor, payer, calendar, quote, or care-history grant.

Canonical Scenario Evidence Handoff

Canonical scenario page: Mother And Family Conversational Booking Scenario Evidence.

Published animated evidence locations:

apps/docs/public/evidence/mother-family-conversational-booking/latest/manifest.json
apps/docs/public/evidence/mother-family-conversational-booking/latest/desktop.webp
apps/docs/public/evidence/mother-family-conversational-booking/latest/mobile.webp
apps/docs/public/evidence/mother-family-conversational-booking/customer-reservation-draft-chat-fb69309/manifest.json
apps/docs/public/evidence/mother-family-conversational-booking/customer-reservation-draft-chat-fb69309/desktop-sequence.webp
apps/docs/public/evidence/mother-family-conversational-booking/customer-reservation-draft-chat-fb69309/mobile-sequence.webp

The customer-reservation-draft-chat-fb69309 evidence uses real Chromium and the 14-section retained-intake server-draft frontend, but its API boundary is a stateful local route mock. Its manifest intentionally sets status=provisional, completionClaim=false, and all backend runtime, deployment, legacy parity, and durable persistence proof flags to false.

The latest path is a publication alias, not immutable proof by itself. Current manifest pins capture time, environment, four repository commits, viewport, source frame hashes, WebP hashes, and browser outcomes; canonical page records known gaps. Before this can support a migration-completion claim, manifest must also carry immutable run id, cleanup result, SFC ids, ADR lineage, generator version/settings, and machine-readable known gaps. Completion claims cite that immutable identity and digest, not only the alias URL. No PII, access token, refresh token, service-role key, raw account field, or private topology may enter frames or manifest.

A-Z Evidence Procedure

A — Authority: read accepted ADR lineage and record any future proposed ADR as non-authoritative until explicit human acceptance.
B — Baseline: pin clean/dirty state and immutable commits for all four repository roles.
C — Coverage: select all eleven cards plus ready_to_submit; map each to source anchors and existing SFC ids on this page.
D — Dataset: create privacy-safe mother, family, branch, plan, calendar, quote, matching, sponsorship, payment, and care-history fixtures.
E — Environment: record stage/local environment name and deployed artifact pins without secrets or private addresses.
F — Fixture auth: refresh or regenerate mother, sponsor, payer, branch, and HQ sessions through the tracked fixture path.
G — Gates before browser: verify backend health, contract compatibility, Supabase/SpiceDB/Restate/Kill Bill dependencies required by scenario, and frontend preview health.
H — Harness: use the tracked bounded Playwright runner; never an untracked manual click diary as canonical proof.
I — Initialize: start one viewport sequence at a time and record initial operational context response.
J — Journey: advance exactly one card per answer and assert no later card is disclosed early.
K — Keep frames: capture each active card, answer transcript, summary disclosure, focus target, and scroll position with stable sequence names.
L — Live commands: for supported variants assert booking POST = 202, workflow query GET = 200, and mother-visible charge summary GET = 200.
M — Mobile: repeat the same semantic scenario at the approved mobile viewport; do not substitute a shorter fixture-only path.
N — Network and console: require zero bad HTTP responses, failed requests, and console errors; retain redacted JSON summaries.
O — Outcome: record request id, booking id, workflow state, frozen quote, payment handoff/readiness, and settlement continuation only from backend responses.
P — Process cleanup: close contexts/browser in finally; prove zero runner, Playwright daemon, headless Chromium, or temporary profile processes.
Q — Quality gates: run frontend focused tests/lint/Astro check/build, assembly pnpm source:check, docs Astro check/build, and relevant backend, contract, architecture, and stage gates.
R — Redaction: scan summaries, frames, logs, and manifest for secrets, PII, raw account fields, private topology, and unsafe provider payloads.
S — Sequence manifest: write ordered source frames, durations, dimensions, viewport, scenario assertions, and artifact checksums into manifest.json.
T — Transcode: generate animated desktop.webp and mobile.webp from the ordered frames with deterministic tool/version/settings recorded in manifest.
U — Upload: publish manifest and WebPs under the approved public evidence directory; never publish raw authenticated storage or unredacted traces.
V — Verify artifacts: recalculate SHA-256, decode both WebPs, verify frame count/order/duration, and confirm manifest paths resolve in built Starlight.
W — Write canonical page: pin run identity, commits, assertions, screenshots, animated WebPs, validation commands/results, and explicit missing variants.
X — Cross-link: link canonical page from this source map and applicable SFC rows; link accepted ADR evidence only within each ADR’s declared scope.
Y — Yield status: advance an SFC status only to the strongest state the run proves. UI animation alone remains UX evidence, never domain parity.
Z — Zero overclaim: keep gaps open for untested sponsor/self-booking, coverage conflict, calendar/suspension, matching, support/coupon, payment, refund, care-history, mobile, admin, or provider variants; remove temporary sessions and test data through the registered reaper.

Binary generation and publication are outside this source-map change. This page defines the evidence handoff and consumption boundary only.

Backend 0676b50eaedbb519c95e30071bfa6a6b3f4a2cc2 closes the hard-coded booking execution-selection gap without promoting legacy numeric IDs to public contract authority. Stable offering, duration or voucher-day, work schedule, exact price-entry code, and authoritative service-day count resolve exactly one versioned source-owned tuple. Label, option order, value, and reservation_amount_hint do not participate. Missing lineage, zero matches, or multiple matches keeps final review partial. The tuple is persisted separately from the exact public final-review payload and fingerprinted with source-policy lineage. Full Python regression is 6,876 passed; Ruff, Tach exact/external, and changed-production Vulture confidence 100 pass. Outbox-to-booking translation, booking workflow execution, and new browser/WebP evidence remain open.

Backend 60334ee0f67ee1a6d355845b8768db194d62c03f extends that tuple with source-owned ISO local start/end times, IANA timezone, and working-time policy revision. This prevents consumer code from guessing hours from legacy working_type_id. Source terms at source-refs/sanmopia_web/application/views/about/terms.php:259-268 define weekday commute 09:00~18:00, Saturday 09:00~14:00, live-in Monday 09:00 through Saturday 09:00, negotiated adjustment, rest, holiday, and evening duties. The simpler customer page confirms commute 09:00~18:00 at application/views/service/kpage06.php:54-60. Assembly 517cd210 adds the stable selection/price/time lineage to the test-owned stage seed. No stage seed, browser, or deployment run occurred.

Backend 384a97a69bb7ff53c6475946611d7da6dce78d4a closes selected-caregiver execution identity gap. Caregiver Matching retains raw candidate_profile_id inside its application result, while reservation option publisher still emits only opaque selection and source authority references. Final review re-resolves current owner, draft request, decision reference/revision, and specific selection or frozen rank one. Only canonical positive execution ID enters internal handoff; stale, unknown, ambiguous, and non-numeric mappings fail closed. Full regression is 6,881 passed. This is not outbox consumption, workflow execution, browser, WebP, or deployment evidence.

Backend 045c145b2cb41d93b29ce8a165bbc39e85c2d31c adds the consumer-owned accepted-projection reader needed after confirmation. Its service-role-only RPC requires one processing outbox fact and exact attempt count, then verifies the command, draft, booking-request, projection revision, confirmation state, and reviewed fingerprint before returning the immutable projection snapshot. It does not reuse the active-draft final-review query after the draft has become confirmed. Migration 20260718113000 is committed but unapplied.

Backend d23b1842ae5f5533e73393c43b68ece894332544 connects that snapshot to the existing reservation-booking workflow through named orchestration. Translation re-resolves branch, versioned service mapping including branchId, selected caregiver, source-owned local time and IANA timezone, accepted quote, payment eligibility/payable, and branch coverage. The internal bearer job claims pending outbox facts, accepts exact workflow replay, and completes or fails the same attempt through CAS. Full regression is 6,900 passed; Ruff and Tach exact/external pass. Vulture confidence 100 reports only five existing Protocol parameter false positives. This closes the local outbox-to-booking-command/workflow-start code gap, not P04: ADR-032 legal acceptance, accepted service-term/offering side-effect assembly, migration application, real Supabase actor E2E, browser/WebP, and deployment remain open.

Backend be9ec4f9230309586ead4002ce7db34d5fb41724 binds the accepted serviceOccurrences to the existing booking ServiceTermPlan. It requires the occurrence count to equal the accepted quote service-day count, contiguous sequence numbers, strictly ordered in-range dates, the accepted end date as the last occurrence, and exactly one calendar-profile and calendar-policy revision. The existing booking workflow can therefore persist its occurrence ledger without inferring dates from legacy numeric service IDs, browser labels, or working-type codes. Focused regression is 25 passed; full regression is 6,902 passed; Ruff, Tach exact/external, and changed-file Vulture confidence 100 pass. This is local code/test evidence. Accepted offering availability, consumer-impact side-effect assembly, and actual Supabase workflow execution remained open at this pin.

Backend b1beee53fec1ca5d0a893841570246ec3f2c6cc3 adds durable recovery for the accepted-booking delivery lifecycle. The service-role-only RPC requeues only an exact failed attempt or a processing attempt older than the server-owned 15-minute cutoff, preserves attempt count for the next claim, and appends an immutable audit snapshot with source status, claim time, error, reason, and actor. An advisory lock and compare-and-set serialize duplicate idempotency keys; exact replay returns the stored result. Focused regression is 60 passed; full regression is 6,917 passed; Ruff, Tach exact/external, and changed-production Vulture confidence 100 pass. Migration 20260718124500 applied verbatim to a scoped disposable PostgreSQL 17.6 database and Supabase CLI schema lint returned error 0. It was not applied to local stage or production and is not clean full-history replay, actor, browser/WebP, or deployment evidence.

Backend fcad4c50f9e07576773adc91548b159350ed275a closes the local accepted offering and consumer-impact assembly gap. The service-offering contribution fingerprint retains the exact availability decision. Final review accepts it only for the selected enabled option and matching policy source revision, then freezes it in the internal booking mapping without changing the public final-review contract. The handoff translator reconstructs the domain decision and uses one application-owned builder for daily-report, settlement, and service-calendar invalidation facts; the existing booking API uses the same builder. Missing metadata or policy drift stays partial or fails closed. Focused regression is 123 passed; full regression is 6,919 passed; Ruff and Tach exact/external pass. Vulture confidence 100 has no new implementation finding; 15 reports are existing Protocol parameter false positives. This is local code/test evidence only: no migration, actual Supabase consumer E2E, browser/WebP, or deployment ran.

Backend 3ac941d59fb7fcfdb35fbf26a69baaeec20d1167 closes the stale final-review catalog scope in the terminal PATCH path. After durable PATCH or exact replay, the application calls an explicit port; named orchestration verifies owner scope, prepares and materializes the exact 26 contributions for the persisted current draft revision, reloads the owner-scoped provider, and passes only that fresh snapshot to final-review materialization. Cross-owner calls fail before publisher writes, and missing current preparation authority fails closed while exact replay safely retries preparation. Focused regression is 21 passed, Tach-affected regression is 411 passed, full regression is 6,921 passed, and Ruff plus Tach dependency/interface/external gates pass. Vulture confidence 100 reports 13 existing Protocol parameter candidates, not deletion authority. This does not create the five preparation-authority source adapters or activate authority recording for every draft, and no migration, actual Supabase actor E2E, browser/WebP, or deployment ran.

Backend 026a8ba4cd17eb87acd084be9017ee292e7ee8dc implements the first of five catalog-preparation source adapters: reservation_state. It reuses the customer-action owner query and revisioned state-mapping policy, so current pre-reservation comes from the modern pre_reservation or pre_reservation_payment_pending lifecycle rather than raw status 15 or a historical pre-reservation flag. Extension intent is accepted only when the owner’s current catalog contains the exact opaque selection; the internal reservation id does not enter the preparation decision. Runtime shares one query handler between the extension catalog publisher and the preparation source. Focused regression is 11 passed, Tach-affected regression is 116 passed, full regression is 6,925 passed, Ruff and Tach dependency/interface/external pass, and Vulture confidence 100 reports no candidate. Source coverage is now 1/5; branch coverage, service-offering policy, price version, voucher criteria, record-authority activation, migration, actual Supabase actor E2E, browser/WebP, and deployment remain open.

Backend dcced6ad461df0b9226a8b61dbebc80a412a31a5 implements the second catalog-preparation source adapter: branch_coverage. The Branch Operations query lists only active sanmopia_branch_profiles that have a positive source_branch_id and one active sanmopia_branch_office_profiles lifecycle, excluding headquarters-internal profiles. It resolves the customer service address and desired start date against every candidate’s existing revisioned service-area policy. Exactly one available branch is required; zero or multiple available branches, consultation-only, unavailable, missing policy, duplicate compatibility id, and malformed lineage all fail closed. The draft does not supply a branch id, and candidate row order never chooses a branch. Address evidence is tagged customer_input, while preparation lineage keeps only the branch-profile reference, policy/profile revisions, matched-rule fingerprint, and daily validity window. Focused regression is 10 passed, Tach-affected regression is 603 passed with 6,308 deselected, full regression is 6,932 passed, Ruff and Tach dependency/interface/exact/external pass, and Vulture confidence 100 finds no changed-production candidate. Source coverage is now 2/5; service-offering policy, price version, voucher criteria, record-authority activation, actual Supabase actor/browser/WebP, and deployment remain open. This slice adds no SQL migration.

Backend 7af3496ba106e976f2e71ab64fbefa749c5a4e83 implements the third catalog-preparation source adapter: service_offering_policy. The owner query selects the draft’s exact serviceOfferingKey within the configured catalog, resolved branch/region scope, and current business date. The selected effective row must carry one explicit source_reference.catalog_preparation_policy object. Service program, service-type detail code, policy revision, and the inclusive pre-reservation day threshold are DB-owned data; no label, row-order, legacy-id, or code-default inference is allowed. Missing metadata, zero or multiple matches, stale validity, and selection drift fail closed. The lineage fingerprint includes source-row UUID, catalog version, policy revision, source-updated timestamp, and evidence key. main constructs the concrete Supabase adapter and injects it through the application port, preserving the orchestration boundary. Targeted regression is 16 passed; Tach-affected regression is 254 passed with 6,668 deselected; full regression is 6,943 passed; Ruff, Tach dependency/interface/exact/external, and changed-production Vulture confidence 100 pass. Source coverage is now 3/5; price version, voucher criteria, record-authority activation, actual Supabase actor/browser/WebP, and deployment remain open. pnpm Supabase CLI 2.109.1 is available, but no local stack is running and this slice adds no SQL migration.

Backend 0809dc2524b65ef5b26ae54a01d2433ad551a35a implements the fourth catalog-preparation source adapter: price_catalog_version. Legacy booking selects and persists PRICE_VERSION_LIST_ID_FK from service program and desired start date; the modern import path now requires that exact positive compatibility identity as source_price_version_id on the normalized price-catalog batch. Neither catalog label, year, row order, nor an ordinal conversion may create the number. A Supabase CLI-created migration adds the field and blocks publication without it. The Pricing Settlement query returns published batches containing the requested program, and the application accepts only one batch effective on the desired start date. Voucher batches must resolve one unique published price_version_key; missing or conflicting keys, overlapping effective candidates, future publication/update timestamps, and malformed lineage fail closed. The reservation decision freezes batch UUID, explicit source id, catalog/version, program, effective window, publication, database fingerprint, and update timestamp. Focused regression is 50 passed; pricing/Supabase regression is 184 passed; Tach-affected regression is 731 passed with 6,205 deselected; full regression is 6,957 passed; Ruff, Tach dependency/interface/exact/external, and changed-production Vulture confidence 100 pass. Source coverage is now 4/5; voucher criteria and record-authority activation remain open. The local Supabase stack is absent, so migration apply, actual actor DB E2E, browser/WebP, and deployment did not run.

Backend 68ce17dc50dbda2139d133120bff411701b91c78 implements the fifth catalog-preparation source: voucher_plan_criteria. It does not translate browser labels, prefixes, or legacy numbers. The persisted birth.baby_types option and its exact quantity bounds prove the canonical baby classification. Approved delivery/workforce and income catalogs then resolve the two submitted option keys and must share one source revision, population, price batch/version, consume-type revision, and fingerprint. The exact published voucher-plan revision is loaded again and compared with those axes. Unknown or guessed keys, baby-count conflict, population or price lineage drift, ambiguous selection, publication payload drift, non-intersecting effective windows, and future publication fail closed. Focused regression is 140 passed; full regression is 6,967 passed; Ruff, Tach dependency/interface/exact/external, and changed-production Vulture confidence 100 pass with zero candidates. Source composition is 5/5, but record activation remains open because the v2 persistence guard still requires the preparation evaluation date and voucher quote date to be equal. This slice adds no SQL migration and ran no actual Supabase actor E2E, browser/WebP, or deployment.

Backend 0934462df40116ed05d580140a639622f74f3fd9 activates the completed five-source composition without collapsing two different business dates. V3 keeps the v2 payload/lineage semantics, requires evaluated_on to equal the database-owned current Asia/Seoul date, and binds quoted_on to the persisted service_schedule.desiredServiceStartOn. It also rechecks the persisted offering selection and baby facts. Terminal PATCH and exact replay now execute five-source resolve, v3 authority record, exact-26 publication, and owner-scoped reload in that order; record failure stops later writes. Scoped PostgreSQL 17 applied v1→v2→v3 and actually recorded/loaded evaluation date 2026-07-18 with future quote date 2026-08-17, projection revision 1, and an unchanged fingerprint. Focused regression is 65 passed, reservation-creation regression is 425 passed, Tach-affected regression is 229 passed with 6,727 deselected, and full regression is 6,977 passed; Ruff, Tach exact/external, and changed-production Vulture confidence 100 pass. The local Supabase stack is absent, so migration apply, actual actor E2E, browser/WebP, and deployment remain open.

Backend ba622266d018ff350bcaec44b7c7c3b400d5d86d adds a retained customer-intake snapshot to the fingerprinted internal accepted booking mapping. It freezes emergency-contact relationship, delivery/baby/older-child/care-center facts, per-baby gender, and pet species/size/separation against eight exact current catalogs with their display labels and catalog/authority lineage. Missing, disabled, ambiguous, malformed, or baby-quantity-incoherent selections fail closed. The accepted booking translator now consumes retained pet facts instead of rehydrating the mutable current operational care environment. Focused integration is 23 passed; application, orchestration, and relevant adapter regressions are 127, 79, and 23 passed; Tach-affected regression is 437 passed with 6,523 deselected; full regression is 6,981 passed; Ruff and Tach pass. Vulture’s three confidence-100 reports are required evaluated_at protocol parameters. At that pin, the then-13-section public projection did not render every retained fact. No migration, actual Supabase actor E2E, browser/WebP, or deployment ran.

Contract 0f5f33324b3a4ee4bad1d40b9faa8d102c0bd5b1, backend 5be421944e279d1e5d916dfb6fe7732c7da732db, and frontend fb69309642e5a400a0b80e7e69df2e304a741493 close that public display/edit gap. The exact-root final-review projection now has 14 required sections, including customerIntakeDisplaySnapshot. Backend derives its contact, birth/baby, and care-environment display facts from the frozen internal snapshot while excluding raw authority and catalog lineage. The Astro final review renders three responsive cards whose own edit actions return to the selected chat step; server-provided downstream invalidation remains authoritative. Contract gates are 486 TypeScript and 82 Python tests, backend reservation-creation focused is 430 passed, Tach affected is 438 passed with 6,523 deselected, backend full is 6,982 passed, and frontend is 575 passed plus Astro check/lint/build. The immutable provisional browser pack customer-reservation-draft-chat-fb69309 contains 39 artifacts and pins all three code revisions. It uses real Chromium but a stateful local API mock, so actual Supabase persistence, deployment, selected regional-support amount, and legal/contract acceptance remain open.

Backend c27a69843196e04af88daf8011afd256a2a421cd adds one repeatable local Supabase full-history gate for this slice. It bootstraps the pinned GoTrue and Storage schemas into a disposable pinned PostgreSQL container, replays all 314 repository migrations through Supabase CLI 2.109.1, validates latest version 20260718170000, runs public-schema lint with error 0, executes the rollback-scoped exact-26 materializer smoke, and proves container/network/temp cleanup. This closes the clean full-history replay evidence gap only; it does not prove stage/production application, non-empty regional-benefit authority, actor/browser confirmation, or ADR-032 legal acceptance. Backend 9d8c6e1460e520823a644ef6a8583c4886962df9 extends that exact clean gate with seven rollback-scoped, data-driven catalog smokes: voucher-plan population, private-care publication, promotion entitlement, reviewed-empty regional support, rental equipment, service priority, and personality. The full history result preserves 26 production publishers and proves 5 rental options, 3 service-priority options, and 6 personality questions with 12 options before rerunning exact-26 materialization. No UI constant becomes catalog authority.

Remaining Completion Matrix

Proof family	Current strongest evidence	Missing before 100% migration claim
11-card interaction	`SFC-20260708-UX-001` foundation; desktop/mobile sequential reveal, transcript, focus/scroll, current-pinned desktop submit/settlement, no browser HTTP/console failures	authenticated mobile submit plus negative/edit/reprojection cases
Mother self-booking	one desktop booking-to-settlement proof under accepted, partial ADR-028; ADR-031 pins contract `8ce891f`, exact projection consumers, two producer boundaries, completed voucher-plan source authority, atomic population, committed exact selection, server-owned selection bridge `b44fd49`, HQ-approved completion `7a9d26e`, exact-26 handler/runtime/CAS at backend `20a79e3`, dormant v1 preparation at `863158c`, five-lineage v2 contracts/handler/Supabase persistence/Seoul-clock evidence at backend `59d29eb`, production publisher registry `26/26` at backend `a325e02f`, partial final-review projection materializer at backend `a7dbc0e7`, retained draft/catalog display facts at backend `48a1c429`, requested schedule occurrences at backend `a759da44`, current-authority branch coverage binding at backend `70ea0ca3`, authoritative service-calendar plan binding at backend `98bf0283`, exact current price-entry quote binding at backend `a4c6ffbd`, pricing-owned charge-snapshot handoff at backend `4166ddf1`, authoritative payment preparation at backend `121f786c`, atomic waiting obligation/public payment handoff at backend `8e7b88bf`, frozen caregiver final-review authority at backend `d29f6b7a`, authoritative empty-support final review at backend `7a345e7b`, selected-promotion amount authority at backend `867ba51f`, selected regional-support quote amount authority at backend `8e37ab8a`, complete accepted discount-only regional-benefit booking handoff at backend `8b214509`, typed confirmation-outbox delivery at backend `b7894b89`, versioned internal booking execution mapping at backend `0676b50e`, accepted projection reader at backend `045c145b`, local booking command/workflow start consumer at backend `d23b1842`, accepted occurrence-ledger plan at backend `be9ec4f9`, durable failed/stale delivery recovery at backend `b1beee53`, accepted offering/consumer-impact assembly at backend `fcad4c50`, current-revision terminal catalog refresh at backend `3ac941d5`, preparation reservation-state source at backend `026a8ba4`, preparation branch-coverage source at backend `dcced6ad`, preparation service-offering-policy source at backend `7af3496b`, preparation price-catalog-version source at backend `0809dc25`, preparation voucher-plan-criteria source at backend `68ce17dc`, source composition `5/5`, v3 split-date persistence and terminal record activation at backend `0934462d`, retained accepted customer-intake snapshot at backend `ba622266`, public retained-intake projection at contract `0f5f333`/backend `5be42194`, final-review-local responsive edit UI at frontend `fb69309`, clean full-history `314`-migration/lint/exact-26 gate at backend `c27a6984`, and seven data-driven full-history catalog smokes at backend `9d8c6e14`	actual Supabase migration/record-load actor proof, runtime E2E axes `0/17`, dependency-scoped contribution refresh, one complete exact-26 current set served without test fixture, preparation/calendar/caregiver/empty-support/promotion/price/payment authority coverage for every draft, legal acceptance, real non-empty regional-benefit Supabase consumer E2E, finalized booking snapshot/readiness activation, corrected-contract stage desktop/mobile evidence, coverage conflict, calendar/suspension, provider callback, refund
Family sponsorship	`SFC-20260711-FAM-001` runtime-wired	card-to-grant/draft/acceptance binding and browser E2E
Delegated payment	`FAM-002` through `FAM-004` runtime-wired	card binding, remaining purposes, provider-live, receipt/refund visibility
Care-history read	`FAM-005` e2e-proven for backend/contract read scope	conversational grant/request binding and mother/family browser proof
Coverage, plan, calendar, matching, quote	backend foundations and broad partial checklist rows	one frozen cross-step projection consumed unchanged by browser and booking workflow
Final legacy removal	not proved	legacy UI/business authority disabled or adapted, source parity acceptance, integrated runtime evidence

Until every row closes with authoritative proof, status remains incomplete.

Mother And Family Conversational Booking Flow Source Map

Classification Summary

Exact 26-Catalog Legacy Authority Audit

17-Axis Preparation Source-Lineage Audit

Step-By-Step Source Mapping

1. family_account

2. mother_profile

3. service_coverage

4. service_plan

5. holiday_suspension

6. caregiver_preference

7. reservation_sponsor

8. payment_delegation

9. pricing_support_payment

10. care_history_visibility

11. booking_details