Customer Account And Reservation Intake Gap Mining

Customer Account And Reservation Intake Gap Mining

Scope: customer-facing account, reservation intake, payment, and document-access behavior from the legacy web source. PHP source is evidence only. Modern work must use Supabase Auth/Profile/RLS, contract-first command payloads, Restate workflow state, Kill Bill payment orchestration, Supabase Storage signed handoffs, and communication delivery audit.

Ubiquitous Names

• CustomerIdentityProfile: Supabase Auth subject, customer profile facts, verified phone/email, marketing consent, push preference, and profile revision.
• CustomerAccountSecurityEvent: sign-in, social sign-in, password reset, password rotation, token revocation, FCM device token lifecycle, and recovery audit.
• ExternalCommerceMemberLink: external shop account linkage, referral code validation, role, shop metadata, social link, and rollback/repair state.
• CustomerReservationIntakeDraft: multi-step reservation wizard state, ownership, process progress, selected service area, and current command state.
• ReservationCarePlanDraft: delivery/baby facts, selected service kind, add-ons, rental equipment, extra Saturday/holiday work, and service-calendar preview.
• ReservationServiceAreaDecision: branch coverage, consultation-only routing, second service address, and regional routing evidence.
• RegionalBenefitPolicy: effective-dated regional benefit rules for extra service days, customer discounts, subsidy adjustments, branch scope, and reservation-impact audit.
• CustomerReservationIntent: customer change, cancellation, stop, extension, birth-data correction, service-start correction, delivery correction, and contact/address correction.
• CustomerPaymentInstruction: customer-visible payment purpose, frozen amount, method, virtual-account instruction, and notification state.
• CustomerDocumentDownloadGrant: signed document/receipt/report download handoff with owner, expiry, artifact scope, and access audit.

Source Component Flow

flowchart LR
  AccountApi[api/Account.php]
  MallApi[Mall.php]
  UserModel[User_model.php]
  ServiceApi[api/Service.php]
  ReservationApi[api/Reservation.php]
  PaymentApi[api/Payment.php]
  ReservationModel[Reservation_model.php]
  PaymentModel[Payment_model.php]

  Identity[CustomerIdentityProfile]
  Security[CustomerAccountSecurityEvent]
  CommerceLink[ExternalCommerceMemberLink]
  Intake[CustomerReservationIntakeDraft]
  CarePlan[ReservationCarePlanDraft]
  RegionalPolicy[RegionalBenefitPolicy]
  Intent[CustomerReservationIntent]
  Payment[CustomerPaymentInstruction]
  Download[CustomerDocumentDownloadGrant]
  Workflow[Restate workflow]
  Kill Bill[Kill Bill]
  Supabase[(Supabase)]

  AccountApi --> UserModel --> Identity
  AccountApi --> Security
  MallApi --> CommerceLink
  ServiceApi --> Intake --> Workflow
  ServiceApi --> CarePlan
  CarePlan --> RegionalPolicy
  ReservationApi --> Intent --> Workflow
  PaymentApi --> PaymentModel --> Payment
  Payment --> Kill Bill
  UserModel --> Download
  Identity --> Supabase
  Intake --> Supabase
  Payment --> Supabase
  Download --> Supabase

Source Evidence And Migration Gaps

Customer Identity, Profile, Consent, And Devices

Source behavior:

• Signup validates email/name/password/phone, stores a raw auth token, marketing push flag, and immediately attempts coupon claim by phone. Evidence: source-refs/sanmopia_web/application/controllers/api/Account.php:31-104 and source-refs/sanmopia_web/application/models/User_model.php:22-33.
• Social sign-in creates partial USER_TB and USER_SOCIAL_TB rows, then redirects users to account completion when required profile fields are missing. Evidence: source-refs/sanmopia_web/application/controllers/api/Account.php:136-153 and source-refs/sanmopia_web/application/models/User_model.php:58-216.
• Profile edit updates identity fields, home address, marketing consent, and again triggers received/sent gift-coupon registration by phone. Evidence: source-refs/sanmopia_web/application/controllers/api/Account.php:154-205 and source-refs/sanmopia_web/application/models/User_model.php:233-289.
• Device token write deletes the previous FCM token by user and token type, then inserts one row. Password change deletes all user tokens and logs out. Evidence: source-refs/sanmopia_web/application/controllers/api/Account.php:206-223, source-refs/sanmopia_web/application/controllers/api/Account.php:272-327, and source-refs/sanmopia_web/application/models/User_model.php:327-394.

Modern gap:

• CustomerIdentityProfile changes need revisioned profile facts. Coupon claim should emit PromotionEntitlementClaimRequested; it must not be a hidden side effect of signup/profile edit.
• CustomerAccountSecurityEvent must record provider subject, device token registration/revocation, password reset/rotation, session invalidation, actor channel, and communication dispatch result.
• Marketing consent needs explicit version, consent text id, source channel, agreed/revoked timestamp, and evidence. It should not be just one mutable flag plus latest timestamp.

External Shop Member Link

Source behavior:

• Mall signup validates email and referral against an external WordPress API, optionally creates a local customer, then calls remote register with role, shop metadata, referral code, marketing agreement, and local suid. Evidence: source-refs/sanmopia_web/application/controllers/Mall.php:12-172.
• Social mall signup and delete write/delete local customer rows around external account behavior. Evidence: source-refs/sanmopia_web/application/controllers/Mall.php:237-285 and source-refs/sanmopia_web/application/models/User_model.php:557-621.

Modern gap:

• ExternalCommerceMemberLink should isolate external commerce membership, referral validation, role/shop metadata, remote id, local profile link, rollback, and retry. Local customer deletion from mall flow must become a repair/cancellation event guarded by privacy retention policy.
• External API URLs, roles, and referral semantics belong in environment and connector config, not controller constants.

Reservation Intake Draft And Service-Area Decision

Source behavior:

• Step 1 blocks new reservation when another customer reservation is in a blocking status, writes home address, selects branch by address, marks consultation-only when branch area policy says consultation or when a second service address exists, geocodes service address, writes emergency contact, and can add a second service address. Evidence: source-refs/sanmopia_web/application/controllers/api/Service.php:12-129.
• Step 2 stores delivery/baby facts up to fourth baby and sets price version by expected service start date. Evidence: source-refs/sanmopia_web/application/controllers/api/Service.php:132-198.
• Service type selection can delete existing voucher/normal service rows, normal/voucher add-option rows, and recalculate price version. It also upgrades service grade when a named caregiver is already selected. Evidence: source-refs/sanmopia_web/application/controllers/api/Service.php:199-278.
• Step 3 mixes voucher/private-care service facts, resident-number validation, Wanju benefit extra days, extra Saturday/holiday days, rentals, service end date, continuation caregiver carryover, consulting flag, and smart-matching routing. Evidence: source-refs/sanmopia_web/application/controllers/api/Service.php:280-576.
• Admin reservation intake exposes regional benefit controls from address sigungu, stores one regional extra-day option and one regional discount flag, and recalculates expected service end date with a hardcoded day addition. Evidence: source-refs/sanmopia-admin/static/js/reservation_status/reservation_add.js:927-948, source-refs/sanmopia-admin/application/controllers/Reservation.php:1320-1349, source-refs/sanmopia-admin/application/controllers/Reservation.php:1739-1758, and source-refs/sanmopia-admin/application/models/Reservation_model.php:4090-4181.
• Customer/admin price readers treat one regional discount as address/service type/flag driven, and additional-service price readers special-case regional extra-day option names. Evidence: source-refs/sanmopia_web/application/models/Reservation_model.php:1164-1295, source-refs/sanmopia_web/application/models/Reservation_model.php:600-625, source-refs/sanmopia_web/application/models/Reservation_model.php:748-768, and source-refs/sanmopia-admin/application/models/Payment_model.php:3748-3825.

Modern gap:

• CustomerReservationIntakeDraft should be a workflow-owned draft with command history, expected revision, and stage-specific allowed actions. Source PROCESS_NO is migration evidence only; modern stages should be explicit state names.
• ReservationServiceAreaDecision should consume versioned BranchServiceAreaPolicy and record branch profile id, coverage kind, second-address reason, geocoding evidence, and consultation routing.
• ReservationCarePlanDraft must preserve care facts separately from price quote facts. Changing service type must supersede affected draft facts and invalidate quote snapshots instead of hard-deleting option rows as the source does.
• RegionalBenefitPolicy must replace region-name branches, source flags, and option-name checks. The policy should store branch/region criteria, service type criteria, benefit kind, amount or day effect, valid period, approval state, and calculation version. Quotes, service calendars, payment conversion, and settlement must consume the same frozen benefit decision.
• Named caregiver selection and smart-matching answers must produce explicit RequestedCaregiverSelection, MatchingProfileCompatibilityInput, MatchingOptimizationInput, and CaregiverCandidateSnapshot facts. Service-grade uplift from named caregiver selection must be a policy result, not controller branching.

2026-07-05 Family And Contact Authority Pass

Missing backend-owned policy	Source evidence	Modern target
Booker, mother profile, service contact, and emergency contact are distinct authority facts. Source Step 1 renders mother name and birth from the login/member profile, defaults the reservation contact phone from reservation/user phone, and collects emergency phone plus relation fields. The API then inserts reservation contact, birth, emergency contact, and relation against the login user’s USER_ID_FK, while also updating the member emergency contact fields.	source-refs/sanmopia_web/application/views/service/step1.php:91-213, source-refs/sanmopia_web/application/controllers/api/Service.php:12-103, source-refs/sanmopia_web/application/models/Reservation_model.php:315-374	ReservationBookerBeneficiarySnapshot, ReservationPartyAuthoritySnapshot, EmergencyContactSnapshot, ContactOnlyRecipient
Emergency contact relation is contact metadata, not payer, refund, document, or consent authority. Source reservation intake persists EMERGENCY_CELLPHONE, RELATION, and RELATION_ETC; payment and document paths still make separate owner/token checks instead of trusting those relation fields.	source-refs/sanmopia_web/application/controllers/api/Service.php:57-81, source-refs/sanmopia_web/application/controllers/api/Payment.php:66-219, source-refs/sanmopia_web/application/controllers/api/ReservationDocument.php:21-42	ReservationConsentAuthority, PaymentAuthorityDecision, DocumentRecipientAuthority, RefundRecipientSnapshot
Draft replacement is keyed to login user, not a resolved reservation party. Source deletes draft reservations for the same USER_ID_FK before inserting a new reservation, then updates the member birthday and cellphone from reservation intake. Modern migration must preserve who performed the command, who the mother/beneficiary is, and which contact values are mutable profile facts versus reservation-time snapshots.	source-refs/sanmopia_web/application/models/Reservation_model.php:315-374	CustomerReservationIntakeDraft, ReservationBookerBeneficiarySnapshot, ReservationPartyAuthoritySnapshot

Customer Reservation Intents

Source behavior:

• Customer can input birth date, service start date, delivery data, and baby rows after reservation creation. Date-complete reservations block some edits. Evidence: source-refs/sanmopia_web/application/controllers/api/Reservation.php:14-85 and source-refs/sanmopia_web/application/controllers/api/Reservation.php:345-451.
• Customer cancellation, stop, and change requests mutate reservation state, then send branch Kakao/SMS. Immediate cancellation also sends customer push. A hardcoded branch id gets an additional phone notification. Evidence: source-refs/sanmopia_web/application/controllers/api/Reservation.php:87-240.
• Customer extension clones original reservation data and returns the new draft id plus voucher eligibility. Evidence: source-refs/sanmopia_web/application/controllers/api/Reservation.php:244-289.

Modern gap:

• CustomerReservationIntent must route customer change/cancel/stop/extension through Restate with idempotency, expected reservation revision, policy result, communication outbox, and branch/HQ task creation.
• Regional notification routing must be a BranchNotificationRoutingPolicy with effective period and branch profile scope. Hardcoded branch-id phone fanout is source evidence only.
• Birth/delivery/service-start corrections need separate command names and stage guards. Updating birth data should invalidate service-calendar preview and price quote through explicit recalculation-needed facts.

Customer Payment Instruction And Document Download

Source behavior:

• Deposit, balance, coupon, pre-reservation, and change-payment flows all call KCP payment code directly, branch by payment purpose, and send virtual-account instructions through Kakao/SMS. Evidence: source-refs/sanmopia_web/application/controllers/api/Payment.php:66-220, source-refs/sanmopia_web/application/controllers/api/Payment.php:223-476, and source-refs/sanmopia_web/application/controllers/api/Payment.php:509-754.
• Payment success paths notify mother and branch. Several branch notifications duplicate an additional regional phone target by source branch id. Evidence: source-refs/sanmopia_web/application/controllers/api/Payment.php:163-220, source-refs/sanmopia_web/application/controllers/api/Payment.php:553-655, and source-refs/sanmopia_web/application/controllers/api/Payment.php:681-754.
• Admin payment-conversion Ajax returns selectable conversion states and then enriches rows by loading reservation price tables, coupon totals, deposited dates, service type, and customer names. Evidence: source-refs/sanmopia-admin/application/controllers/ajax/Reservation.php:68-174. Migration must make ReservationPaymentConversionProjection backend-owned: converted status, original payment purpose, frozen coupon discount, customer share amount, deposited-at fact, and allowed follow-up command must come from a typed read model, not client or controller ad hoc PRICE_TABLE traversal. Implementation note: backend domain/application contract slices now live under backend-repo/src/sanmopia_modernization/{domain,application}/pricing_settlement/features/payment_conversion/. They require caller-supplied ids, revisions, timestamps, frozen amounts, deposited-at facts, service type/kind codes, and backend-selected follow-up command. Persistence/API wiring remains a follow-up integration task.
• Document download token is a two-hour USER_TOKEN_TB row with type documentDownload. Evidence: source-refs/sanmopia_web/application/models/User_model.php:462-491.

Modern gap:

• CustomerPaymentInstruction should be created before payment UI entry, freeze purpose, amount, provider, method, virtual-account data, expiry, message state, and customer-visible status. Kill Bill verification/webhook remains backend-owned; customer portal reads a safe projection only.
• Payment-purpose notifications belong to communication workflows with delivery audit and branch routing policy, not inline controller sends.
• CustomerDocumentDownloadGrant should map artifact id, document kind, reservation id, customer profile id, signed URL expiry, issued actor, and access audit. It should not reuse the generic auth/device token table.

Feature-Level Queue

• Backend/contract: CustomerIdentityProfile profile-revision projection with marketing consent evidence and phone/email verification state.
• Backend/contract: CustomerAccountSecurityEvent for social completion, password reset/rotation, FCM token registration, token revocation, and account recovery audit.
• Backend/contract: ExternalCommerceMemberLink connector workflow for WordPress/shop membership, referral validation, local profile link, and rollback/repair.
• Backend/contract: CustomerReservationIntakeDraft Restate workflow and stage-capability projection replacing source PROCESS_NO.
• Backend/contract: ReservationServiceAreaDecision using BranchServiceAreaPolicy, geocoding evidence, second-address reason, and consultation routing.
• Backend/contract: ReservationCarePlanDraft supersession/invalidation for service type, delivery/baby facts, add-ons, rentals, selected extra Saturday/holiday work, Wanju benefit, and service-calendar preview.
• Backend/contract: CustomerReservationIntent command set for birth, service-start, delivery, change, cancel, stop, and extension.
• Backend/contract: CustomerPaymentInstruction projection across deposit, balance, coupon, pre-reservation, change-payment, and virtual-account instruction workflows.
• Backend/contract: ReservationPaymentConversionProjection for admin/customer payment conversion rows. Status: implemented as backend domain/application contracts in pricing_settlement/features/payment_conversion/; persistence/API wiring remains open.
• Backend/contract: CustomerDocumentDownloadGrant for signed Supabase Storage handoff and access audit.
• Backend/docs: BranchNotificationRoutingPolicy for branch-specific extra recipients without source branch-id hardcoding.