Weekly Service Calendar And Refund Gap Mining

Weekly Service Calendar And Refund Gap Mining

This page records legacy PHP/JS behavior evidence only. It is not a porting plan and should not copy the legacy control flow. The target model should preserve the business facts as explicit domain language: ServiceCalendarPolicy, ServicePeriodPlan, ServiceDayOccurrence, ServiceSuspension, HolidayPolicyVersion, RefundAdjustmentCatalog, ProductPricingPlan, and BranchCoveragePolicy. Regional support terms use RegionalBenefitPolicy, ResidencySupportProfile, and CoverageProfileKey; legacy locality labels stay source evidence only.

Ubiquitous Language

Name	Meaning for the migration
ServiceCalendarPolicy	Computes the expected service end date and generated service occurrences from period, holiday, branch, and selected extra-day inputs.
ServiceWeekProfile	Canonical service-calendar profile for service-week length and weekend workday inclusion; source one-week/two-week labels are evidence only.
ServiceDurationProfile	Effective-dated duration profile for day/week basis, Wanju or service-area extension, and historical end-date compatibility mode.
ServicePeriodPlan	Immutable plan for service term, week/day basis, start/end dates, extension link, region, branch, and benefit modifiers.
ServiceDayOccurrence	One generated date in the plan, including weekday service, skipped weekend, skipped holiday, added Saturday, added holiday, or suspension boundary facts.
ReservationServiceOccurrenceLedger	Frozen reservation occurrence ledger consumed by reports, assignment, pricing, refund, settlement, and benefit issuance.
ServiceSuspension	Durable pause interval with request, effective stop, and resume facts. Legacy infers this from status logs; modern code should not.
HolidayPolicyVersion	Versioned holiday publication with source kind, effect, reason, scope, fingerprint, announcement date, duplicate-date change decision, substitute-of relation, and supersession facts.
CreditedServiceDayBenefitEntitlement	Pricing/promotion decision that issues, resets, or suppresses coupon/benefit entitlement from credited service-day facts.
RefundAdjustmentCatalog	Named refund adjustments for cancellation timing, used service, gifts, delivery, coupon restore, benefits, and operator corrections.
ProductPricingPlan	Product/payment plan separating service price, add-on day price, deposit, balance, pre-registration, coupon, point, voucher, and correction lines.
BranchCoveragePolicy	Decides which branch owns an address/date range and how split-address or continuation service is routed.
CoverageProfileKey	Stable branch/service-area profile key selected by address/date policy; source city/county labels do not become modern branch names.
ResidencySupportProfile	Effective-dated regional support profile with eligibility evidence, service-day bonus count, and settlement participation code.
RegionalBenefitPolicy	Resolves regional support metadata into one frozen benefit decision consumed by price, calendar, payment-conversion, and settlement workflows.

flowchart LR
  subgraph ReservationOperations[reservation_operations components]
    Coverage[BranchCoveragePolicy]
    CoverageKey[CoverageProfileKey]
    Calendar[ServiceCalendarPolicy]
    Plan[ServicePeriodPlan]
    Occurrence[ServiceDayOccurrence]
    Suspension[ServiceSuspension]
  end

  subgraph PricingSettlement[pricing_settlement components]
    Regional[RegionalBenefitPolicy]
    SupportProfile[ResidencySupportProfile]
    PriceSummary[ReservationPriceSummary]
    Charge[CustomerChargeSnapshot]
    SettlementParticipation[SettlementParticipationDecision]
    Refund[RefundAdjustmentCatalog]
  end

  subgraph ExternalEvidence[source evidence and imported facts]
    CustomerWizard[Customer step3 JS]
    AdminEdit[Admin reservation edit]
    HolidayAdmin[HOLIDAY_TB admin]
    KoreaHolidaySeed[OSS Korean holiday seed]
    SourceRegional[Legacy locality/support flags]
    StopLogs[Stop/status logs]
  end

  CustomerWizard --> Calendar
  AdminEdit --> Calendar
  HolidayAdmin --> Holiday[HolidayPolicyVersion]
  KoreaHolidaySeed --> Holiday
  Holiday --> Calendar
  Coverage --> CoverageKey
  CoverageKey --> Regional
  SourceRegional --> SupportProfile
  SupportProfile --> Regional
  Regional --> PriceSummary
  PriceSummary --> Calendar
  Calendar --> Plan
  Plan --> Occurrence
  Calendar --> SettlementParticipation
  PriceSummary --> Charge
  StopLogs --> Suspension
  Refund --> RefundIntent[PaymentRefundIntent]

Source Evidence

Weekly Service Period And Occurrences

Legacy calculates a service end date in more than one path.

• source-refs/sanmopia_web/application/models/Reservation_model.php:463-485 has the older calcServiceEndDate() path. Voucher day counts are converted as five service days per seven calendar days. Normal service looks up LIST_NORMAL_SERVICE_DAY_TB, treats the value as one-week/two-week service, and shifts an end date that lands on Sunday or Saturday.
• source-refs/sanmopia_web/application/models/Reservation_model.php:2515-2630 has the newer getEndDateCalc() path. It accepts weeks, selected Saturday/holiday lists, and a Wanju option, loads HOLIDAY_TB, counts only Monday-Friday non-holidays, skips Sundays and Saturdays, and extends to the latest selected added Saturday or holiday.
• source-refs/sanmopia_web/static/js/step3.js:603-611 derives the selected service week differently for voucher and normal reservations.
• source-refs/sanmopia_web/static/js/step3.js:861-911 posts start_date, weeks, is_week, selected saturday_list[], selected holiday_list[], and is_wanju to /api/reservation/getServiceExpectEndDate.
• source-refs/sanmopia_web/application/models/Reservation_model.php:642-663 stores SERVICE_DAY_LIST_ID_FK, start date, and end date in RESERVATION_SERVICE_NORMAL_TB.
• source-refs/sanmopia_web/application/controllers/Reservation.php:651-1021 lets the admin edit expected/start/end dates, service term, Saturdays, holidays, payment dates, and other reservation facts in one broad mutation, then writes before/after change-log data.

Modern gap:

• ServiceCalendarPolicy should be the single backend calendar authority for both customer and operator paths.
• Canonical owner: top-level service_calendar. Use ServiceWeekProfile / ServiceDurationProfile for service-week length, weekend workday indices, duration-extension profile, and historical compatibility mode. reservation_operations should consume frozen service-calendar decisions and reservation-scoped occurrence snapshots, not own parallel service-week math. Backend commit fee19fe adds the first profile-backed domain/application foundation: a six-day service-week profile can promote Saturday into base service, keeps Sunday skipped, and blocks selected-extra-service duplication for dates already counted as base service.
• ServiceCalendarTerm.service_days_per_week and PlanServiceCalendarPayload.service_days_per_week now remove the baked-in five-day service week assumption. Six-day or branch-specific service-week plans can pair that value with weekend_workday_indices instead of adding another one-week/two-week product branch.
• SupabaseServiceCalendarPolicyProfileReader now selects service-area calendar policy profiles by branch profile, matched service-area profile key, matched service-area rule evidence, address scope, effective date, and policy fingerprint before falling back to global profile data. This replaces source locality flags as runtime behavior while preserving them as migration evidence only.
• ServicePeriodPlan should store the chosen policy version and the generated occurrence snapshot so later price, report, caregiver, and refund workflows do not silently recalculate against current holiday rows.
• Migration needs a compatibility decision for reservations created by the older weekend-shift path versus the newer weekday-counting path.
• Admin edits should be split into explicit commands instead of one mutable catch-all form post.

Weekend, Holiday, And Extra-Day Handling

Legacy separates Saturday additions from holiday additions.

• source-refs/sanmopia_web/application/models/Reservation_model.php:2710-2741 returns non-holiday Saturdays from DATE_LIST_VW and holidays from HOLIDAY_TB.
• source-refs/sanmopia_web/static/js/step3.js:1091-1147 fetches /api/reservation/getSaturdayAndHoliday/{startDate} and renders separate Saturday and holiday options.
• source-refs/sanmopia_web/static/js/step3.js:478-561 recalculates added Saturday and holiday price rows from selected option count.
• source-refs/sanmopia_web/static/js/step3.js:944-949 tells customers that Sunday service is not recommended and only public holidays can be requested as added service periods.
• source-refs/sanmopia-admin/application/models/Manage_system_model.php:10-26 reads holidays from HOLIDAY_TB joined to LIST_HOLIDAY_TYPE_TB.
• source-refs/sanmopia-admin/application/models/Manage_system_model.php:52-109 creates a holiday type from free text when needed and inserts a new HOLIDAY_TB row after duplicate-date validation.
• source-refs/sanmopia-admin/application/models/Manage_system_model.php:112-181 edits or deletes the same date row by HOLIDAY_DT_PK. Free-text LIST_HOLIDAY_TYPE_TB.VALUE is the only type evidence, so substitute holiday, self/company holiday, branch closure, and paid extra-service meaning cannot be trusted from the label alone.
• source-refs/sanmopia-admin/application/controllers/ajax/ManageSystem.php:16-32 returns only date strings for the admin calendar endpoint.
• source-refs/sanmopia_web/application/models/Reservation_model.php:2515-2630 consumes only date membership from HOLIDAY_TB when computing service end date; substitute-holiday cause and branch/company closure scope are unavailable to the calculation.
• source-refs/sanmopia_web/application/models/Reservation_model.php:463-486 calculates older service duration by multiplying voucher or normal service day values into a week span and then shifting end dates around weekends, while source-refs/sanmopia_web/application/models/Reservation_model.php:2515-2630 uses newer weekday-count logic with Wanju-specific extension math. The modern calendar must preserve which compatibility mode produced historical dates.
• source-refs/sanmopia_web/application/models/Report_model.php:324-339 and source-refs/sanmopia_web/application/models/Report_model.php:451-466 exclude weekend and HOLIDAY_TB dates from report selection, with service-end exceptions. Report, refund, settlement, and assignment consumers need one generated occurrence projection instead of reimplementing holiday exclusion.
• source-refs/sanmopia_web/application/models/Reservation_model.php:2526-2612 mixes weekly/day duration, selected Saturday/holiday boundary extension, and the source locality flag that adds five billable service days. The locality label is source evidence only; modern backend treats it as residency_support_bonus_week plus support_service_days_bonus profile data.
• source-refs/sanmopia-admin/application/controllers/Reservation.php:1749 and source-refs/sanmopia-admin/application/models/Reservation_model.php:5379-5408 compute a similar support extension through a different calendar-day path. Imports must reconcile those rows through compatibility decisions, not copy the controller branch.
• source-refs/sanmopia-admin/application/controllers/Reservation.php:1740-1758 adds seven calendar days for a source locality flag before delegating to the admin model, while source-refs/sanmopia-admin/application/models/Reservation_model.php:5376-5418 extends for non-weekend holidays and then moves a Saturday or Sunday final end date backward. Needs source confirmation: comments describe adding days, but the inspected weekend adjustment subtracts days, so imports should preserve historical stored end dates and flag operator review before normalizing this path.

Modern gap:

• HolidayPolicyVersion should distinguish public holiday, substitute holiday, company holiday, branch closure, and serviceable extra-day effects. Legacy free-text holiday type is not enough.
• Holiday rows need source, announcement date, effective range, substitute-of date, supersession, fingerprint, scope, and audit facts. The date-only calendar endpoint loses policy meaning and cannot explain sudden substitute-holiday invalidation after a reservation quote or caregiver assignment already exists.
• ServiceCalendarCompatibilityDecision should identify legacy weekend-shift, newer weekday-count, source duration-extension profile, and selected extra-day modes, plus the admin new-reservation holiday/weekend rollback mode, so old reservations can retain their original interpretation while new reservations use the canonical policy. Legacy region tokens remain source evidence only; modern policy uses profile keys and adjustment keys.
• 2026-07-05 controller/view follow-up: admin reservation creation still shows locality-specific benefit fields and builds wanju payload fragments in UI code (source-refs/sanmopia-admin/static/js/reservation_status/reservation_add.js:927-941, source-refs/sanmopia-admin/static/js/reservation_status/reservation_add.js:1519-1539, source-refs/sanmopia-admin/application/views/reservation_status/reservation_add.php:273-303). Target name is ResidencySupportProfile, not a city/county branch. Backend RegionalBenefitRule metadata now carries regional_benefit_profile_key, source_option_key, service_day_bonus_count, service_end_date_delta_days, and settlement_participation_code. FinalizeReservationChargeWithRegionalBenefitHandler resolves the regional benefit once, builds ReservationPriceSummaryInput, and freezes profile, service-day bonus, end-date delta, source-option evidence, and settlement participation facts as RegionalBenefitChargeImpactSnapshot entries on the finalized charge snapshot. Remaining work is runtime binding so service calendar, payment conversion, refund, and settlement consumers read that same frozen impact path.
• BranchServiceAreaPolicyDecision now carries coverage_profile_key and service_calendar_policy_profile_key from the matched address rule. This keeps special residency/support areas as versioned profile data instead of spreading locality string checks into reservation, pricing, or UI code.
• ServiceDayOccurrence should preserve why a date was skipped or added, and whether the addition changes price, end date, caregiver assignment, or settlement. Backend progress now emits customer_benefit_entitlement_review_required as a calendar impact when a selected extra Saturday/holiday service day exists, so coupon/compensation rules can be handled by promotion/benefit consumers instead of UI totals or calendar code.
• Runtime follow-up: ReservationServiceOccurrenceLedger should be the frozen input for holiday/suspension/report/refund/settlement consumers, while pricing_settlement / CreditedServiceDayBenefitEntitlement owns coupon or benefit issuance from credited service-day facts. Browser counts, HOLIDAY_TB date membership, and PHP report exclusions are source evidence only.

Continuation And Branch Coverage

Legacy continuation is a new reservation linked to an old reservation.

• source-refs/sanmopia_web/static/js/mypage/reservation.js:424-464 starts a continuation request and redirects into a new reservation step flow.
• source-refs/sanmopia_web/application/controllers/api/Reservation.php:244-290 validates login, ownership, and continuation eligibility before creating the linked reservation.
• source-refs/sanmopia_web/application/models/Reservation_model.php:2052-2089 blocks a second continuation when the linked new reservation has progressed beyond draft/writing status.
• source-refs/sanmopia_web/application/models/Reservation_model.php:2091-2233 copies step1, address, delivery, matching, preference, and memo-like facts into the continuation reservation and writes RESERVATION_CONTINUE_TB.
• source-refs/sanmopia_web/application/models/Reservation_model.php:2474-2502 walks the continuation chain and prevents voucher continuation when the original chain already used voucher service.
• source-refs/sanmopia_web/static/js/step1.js:404-413 documents a split address case: one week at a family home and one week at the mother’s home is handled by booking the first region/period and waiting for branch manager follow-up.
• source-refs/sanmopia_web/application/models/Branch_model.php:38-144 performs branch lookup by address depth and consultation/impossible markers. source-refs/sanmopia-admin/application/models/Branch_model.php:288-334 lists possible, consultation, and impossible areas, while source-refs/sanmopia-admin/application/models/Branch_model.php:337-426 permits consultation/impossible rules only inside possible areas.
• source-refs/sanmopia-admin/application/models/Branch_model.php:590-606 hard-deletes service areas without policy revision or audit, and source-refs/sanmopia_web/application/controllers/api/Service.php:792-811 rejects a picked caregiver from another branch through a local branch check.

Modern gap:

• ServicePeriodPlan.extensionOf should link continuation plans without blindly copying mutable facts.
• BranchCoveragePolicy should make branch ownership explicit for split-address and continuation service periods, including Daum address-level normalization, possible/consultation/impossible precedence, branch-transfer or other-area decisions, actor/reason audit, and booking-time coverage snapshots.
• Continuation voucher eligibility should be a named policy result, not a query hidden in reservation-copy logic.

Pause, Stop, And Resume

Legacy has a stop request, but no durable suspension aggregate.

• source-refs/sanmopia_web/static/js/mypage/reservation.js:330-422 sends customer change/cancel/stop requests with a reason to /api/reservation/request/{command}.
• source-refs/sanmopia_web/application/controllers/api/Reservation.php:87-240 branches by cancel, stop, and change, then notifies branch users.
• source-refs/sanmopia_web/application/models/Reservation_model.php:1091-1112 sets status to RESERVATION_STATUS_STOP_REQ and writes RESERVATION_REQUEST_TB.
• source-refs/sanmopia_web/application/models/Report_model.php:268-392 infers stop intervals from RESERVATION_CHANGE_LOG: rows whose after data contains stop mark stop start, rows whose before data contains stop mark stop end, and service reports filter dates inside that inferred interval.
• source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4028-4048 treats service start, service end, and isStopDay(...) as first/middle/final daily-report export variants, so document/report export also consumes the occurrence ledger.

Modern gap:

• ServiceSuspension should store requested, approved, effective stop, resume, and reason facts directly. Backend domain/application foundation now models ServiceSuspensionRequest, ServiceSuspensionApproval, ServiceResumeBoundary, and ServiceSuspensionImpactPlan; the plan emits follow-up commands for calendar occurrences, caregiver assignment, pricing/settlement, refund quote, daily report, and customer communication.
• Stop confirmation and resume must be reservation collaboration mutation kinds with expectedRevision, stale-save conflict response, and workspace commit_conflicted logging. A stopped service period changes calendars, reports, coupons, refunds, and settlement, so it cannot remain a free status edit outside the realtime conflict contract.
• Reports, pricing, caregiver assignment, and refunds should consume suspension intervals from the domain model rather than parsing change-log text.
• Document/report export, settlement, and coupon reset should consume the same ReservationServiceOccurrenceLedger plus suspension facts, including a stop-day final-report marker.

Pricing, Coupon, Benefit, Payment, And Refund

Legacy pricing combines calendar, product, coupon, and local benefit rules.

• source-refs/sanmopia_web/application/models/Reservation_model.php:47-66 loads normal price catalog rows and joins Saturday add-option price.
• source-refs/sanmopia_web/application/models/Reservation_model.php:1847-1882 loads voucher price by service detail, baby type, delivery count, consume type, service day, and price version.
• source-refs/sanmopia_web/application/models/Reservation_model.php:1115-1373 builds the latest reservation price view. It derives service days from normal weeks or voucher days, adds selected Saturdays and holidays, multiplies most add-ons by service day count, treats Saturday/holiday as selected-day counts, applies coupon and pre-reservation discount facts, and calculates customer charge and remaining payment amounts.
• source-refs/sanmopia_web/application/models/Payment_model.php:101-281 processes downpayment. It marks coupons used, creates customer-share deposit, customer-share balance, and service-balance payment rows, handles virtual account wait state, grants point/shopping-mall coupon when coupon and pre-reservation credit exceed customer own price, and calls RESERVATION_DATE_INSERT_FN.
• source-refs/sanmopia_web/application/models/Reservation_model.php:990-1066 handles cancellation request. Some cancellations are instant when birth date is at least fourteen days away or the reservation is pre-reservation; instant cancellation calls payment refund, reopens used coupons, marks Momfirst rows deleted, updates reservation status, and writes request logs.
• source-refs/sanmopia_web/application/models/Payment_model.php:384-441 refunds provider payment contexts by calling KCP refund and marking normal and voucher payment rows as refund status. It does not expose a partial refund quote formula.
• source-refs/sanmopia_web/application/models/Coupon_model.php:530-552 restores used coupons by setting USE_FL=0, clearing use date, and writing a coupon reuse log.
• source-refs/sanmopia-admin/application/models/Coupon_model.php:218-323 creates product coupon rows only for normal service. One-week service gets PRODUCT1 20,000 with PUBLISH_DT = start + 3 days; two-week-or-longer service gets PRODUCT2 30,000 with PUBLISH_DT = start + 3 days for live-in working type and start + 8 days otherwise. Continuation only issues when the original was voucher and the new reservation is normal.
• source-refs/sanmopia_web/application/controllers/cli/Reservation.php:302-360 grants USER_COUPON_TB only when the source day difference equals 15, with six-month expiry, while excluding stopped/cancelled/raw inactive statuses.
• source-refs/sanmopia-admin/application/models/Coupon_model.php:33-161 resets product coupons on normal-service stop/cancel from MANAGER_ATTENDANCE_TB: no coupon for two or fewer attended days, one-week PRODUCT1 for three to seven, and two-week PRODUCT2 for eight or more, with immediate user-coupon grant and six-month expiry.
• source-refs/sanmopia-admin/application/models/Payment_model.php:872-886, source-refs/sanmopia-admin/application/models/Payment_model.php:896-933, and source-refs/sanmopia-admin/application/models/Payment_model.php:966-979 make branch settlement consume occurrence timing through stopped-voucher eligibility, service-end-plus-one-month period selection, coupon grant month, deleted-coupon commission bands, and other-area settlement counts.

Modern gap:

• ProductPricingPlan should be the catalog boundary for service price, selected extra-day price, voucher price, deposit, balance, pre-registration, coupon, point, delivery, rental, and correction lines.
• Reservation views also compute totals directly: source-refs/sanmopia_web/application/views/reservation/retc.php:3-19, source-refs/sanmopia_web/application/views/reservation/retc.php:47-76, source-refs/sanmopia_web/application/views/reservation/retc.php:159-191, and admin reservation price tables recompute coupon, prepayment, voucher add-on, and service-balance fields. These UI totals are evidence only; backend quote snapshots must be financial authority.
• RefundAdjustmentCatalog should name cancellation timing rules, used-service deductions, extra-day effects, coupon restoration, benefit reversal, delivery or gift deductions, operator overrides, and provider refund intent behavior.
• Payment/refund code should expose quote snapshots before execution and record provider partial-cancel state transitions separately from reservation status.
• CreditedServiceDayBenefitEntitlement should reconcile scheduled entitlement date, actual grant, stop/cancel reset, restore suppression, notification, and settlement recognition from frozen occurrence/attendance facts. Source SERVICE_START_DT + N days, diffDay == 15, and attendance row counts are compatibility evidence, not new policy authority.

Backend Gap Checklist

Domain object	Status	Missing backend proof
ServiceCalendarPolicy	Partial	Foundation exists in the modern checklist for service calendar planning. ServiceCalendarPolicyProfile now carries profile key, duration adjustment key, and extension days, and SupabaseServiceCalendarPolicyProfileReader selects active global, branch, service-area profile, matched-rule, and address-scope snapshots by effective date. Region-specific source labels are data/evidence instead of branch code or target commands. Remaining work: runtime command/API consumers still need one canonical calendar authority for every reservation mutation path.
ServicePeriodPlan	Partial	service_days_per_week is now explicit in backend/calendar contracts. Remaining work: immutable occurrence snapshots tied to policy version, extension link, branch decision, selected extra days, and pricing basis.
ServiceCalendarCompatibilityDecision	Partial	Backend/domain/application now decides historical compatibility through preserve_source_service_end, use_current_policy, or require_operator_review, and POST /service-calendar-compatibility-decisions exposes the branch-scoped contract with Supabase Auth plus branch view permission. Stored impact reads now expose the persisted decision through GET /reservation-service-calendar-impacts/{reservationBookingId} so consumers can read frozen policy evidence. Service-calendar plan snapshots now freeze and persist policy_profile_key, duration_adjustment_key, duration_extension_days, service_duration_profile_key, duration_profile_evidence_key, and service_end_date_policy; ReservationContinuationLink now models original/new booking ids, copied-fact audit, branch coverage evidence, and same-caregiver availability as continuation facts, with backend-owned Supabase sanmopia_reservation_continuation_links persistence. Remaining work: bind decisions from every reservation creation/change path, store detailed copied-fact audit rows, wire caregiver schedule readers, and make pricing, matching, settlement, and refund consumers read this projection.
ReservationServiceOccurrenceLedger	Partial	Generated occurrence impact planning now fans out selected extra service days to pricing, refund, settlement, caregiver-assignment, report, document export, and customer-benefit entitlement review consumers. Care-delivery now has ReservationServiceOccurrenceObligationProjector, service_occurrence_evidence_key, attendance expectation, and daily-report requirement binding so report/attendance can consume occurrence facts instead of raw date rows. Daily-care print submissions now require service_occurrence_evidence_key. Backend 2085085 adds the top-level service_calendar ledger projection from ServiceTermPlan, including stable occurrence evidence keys, credited service-day sequence, skip reason, selected extra-day linkage, holiday keys, and Pydantic projection validation. Backend 5108868 persists frozen ledgers and queryable occurrence entries in Supabase tables sanmopia_reservation_service_occurrence_ledgers and sanmopia_reservation_service_occurrence_ledger_entries, with RLS, service-role grants, snapshot JSON checks, credited-sequence invariants, and stage migration proof. Backend bbde5e2 adds ReservationServiceOccurrenceLedgerCommandHandler, the application command path that projects a ServiceTermPlan and writes the frozen ledger through the persistence port. Backend 7289fd4 wires successful reservation booking to that command when an accepted ServiceTermPlan is present; the application-level booking test creates a reservation and persists the occurrence ledger. Backend 7f7e061 exposes accepted ServiceTermPlan intake through HTTP/ReState reservation-start payloads via acceptedServiceTermPlan; focused boundary tests prove the command carries computed base/additional occurrence counts. Backend 87a3021 wires the Supabase booking runtime to SupabaseReservationServiceOccurrenceLedgerStore and proves a successful Supabase-backed booking writes ledger and entry upserts while returning service_occurrence_ledger_key. Backend 26864d8 adds a revisioned occurrence-ledger command and shared key builder, so admin/change paths can persist v2+ ledgers instead of mutating the original booking snapshot. Backend 70b4b67 adds ReservationServiceTermMutationCommandHandler, requiring an expected previous ledger, rejecting existing target revisions, and preserving actor/reason source evidence before writing a new revision. Backend f3d87e5 exposes the service-term mutation API/HTTP endpoint with Supabase Auth, SpiceDB reservation manage permission, and focused Pydantic boundary tests. 2026-07-07 follow-up: service-term mutation now requires branch_service_area_decision_evidence_id whenever the new plan changes the service-area profile, and the command/API/HTTP boundary carries expected_reservation_revision; SupabaseReservationServiceTermMutationRevisionReader now reads sanmopia_reservation_bookings.revision_number in the composition root, so stale admin saves are rejected against the live reservation revision before writing a revised occurrence ledger. The operator draft application HTTP route now accepts source form evidence, validates it against backend-owned PlanServiceTermPayload, and rejects broad-save payment/status fields before command execution; TS contracts now expose the route builder, request/response types, and validators. Backend supabase:smoke:stage:reservation-booking now proves the live FastAPI/ReState/Supabase path: branch operator starts a booking, progress reaches completed, and workflow audit keeps requested_by_user_id as the branch actor. Remaining work: bind concrete legacy save/change callers to the mutation route, persist precise service-address evidence links, promotion execution outbox, settlement recognition, and final-report export to persisted ledger facts.
HolidayPolicyVersion	Partial	Backend now exposes policy change decisions through POST /service-calendar-holiday-change-decisions, so legacy add/modify/delete and duplicate-date alerts are normalized into creation, revision, withdrawal, idempotent replay, or operator selection results against active policy rows. Remaining work: accepted-decision execution, provider import execution, substitute-of relation persistence, announcement time, supersession, and quote/assignment invalidation.
ServiceSuspension	Partial	Domain/application contract foundation now creates durable request, approval, resume-boundary, affected-date, and cross-context impact facts. ReservationPromotionSideEffectPlan now covers stop product-coupon reset without used reservation coupon restore. Remaining work: Supabase persistence, command/query APIs, collaboration mutation binding for stop/resume, report/export consumers, side-effect outbox execution, stopped-voucher settlement eligibility, and realtime conflict event logging.
CreditedServiceDayBenefitEntitlement	Partial	Source product coupon entitlement mixes planned publish dates, CLI grant timing, attendance-day reset bands, notification, and branch settlement recognition. Remaining work: one pricing/promotion entitlement decision sourced from ReservationServiceOccurrenceLedger, actual attendance facts, interruption kind, settlement recognition period, notification grant, and repairable outbox.
ProductPricingPlan	Partial	2026-07-06 backend delta: enterprise_pricing_product pure domain slice now models product catalog identity, effective periods, attributes, custom discount/surcharge/support/refund/deposit lines, and Kill Bill invoice-line draft terms without UI amount authority. Remaining work: wire application/Supabase/API contracts and make service-calendar add-day pricing, voucher price basis, benefit over-credit, and operator correction usage consume this catalog boundary.
RefundAdjustmentCatalog	Partial	Gateway-cancellable cancellation refunds now persist quote explanation snapshots with catalog version and deduction lines. Remaining gaps: zero-gateway-refund quote persistence, coupon/benefit restore behavior, provider partial-cancel events, and operator override catalog entries.
BranchCoveragePolicy	Backend + contract	Split-address and continuation branch behavior is manual in source. Modern backend has revisioned branch service-area policy, matched-rule profile keys for coverage/calendar follow-up policy, and a Supabase decision recorder for booking-linked BranchServiceAreaDecisionSnapshot evidence. 2026-07-07 follow-up: booking workflow start now accepts serviceAddress, resolves and records backend branch coverage before booking, blocks unavailable coverage, and carries frozen branchCoverageDecision through Restate and TS/Pydantic contracts. Continuation draft creation now rejects copied address/service-area facts unless branch_service_area_decision_evidence_id is present, so the backend no longer permits blind continuation address cloning. Service-term mutation now also requires branch coverage evidence before a post-booking service-area profile change can write a revised occurrence ledger. Remaining work: bind second-period and extension workflows to the same recorder, persist the continuation draft plan through runtime/API paths, add a precise service-address evidence link, then make pricing, matching, settlement, refund, and conflict readers consume the frozen coverage decision.
RegionalBenefitPolicy	Partial	Backend profile metadata now stores regional_benefit_profile_key, source_option_key, source_evidence_key, own_price_adjustment_krw, service_day_bonus_count, service_end_date_delta_days, and settlement_participation_code on RegionalBenefitRule. RegionalBenefitEligibilityDecision is the forward domain name for the decision, while existing RegionalBenefitDecision consumers remain compatible. FinalizeReservationChargeWithRegionalBenefitHandler resolves one decision, builds ReservationPriceSummaryInput, and freezes profile/source-option/service-day/end-date/settlement facts as RegionalBenefitChargeImpactSnapshot entries in FinalizedReservationChargeSnapshot and Supabase regional_benefit_charge_impact_snapshots. Booking HTTP/API boundaries and TS/JSON contracts accept acceptedRegionalBenefitDecision lines with nullable sourceEvidenceKey, so UI/admin locality labels can be retained only as policy evidence. Refund requotes now require the matching finalized charge snapshot id plus frozen regional-benefit line event ids through RegionalBenefitRefundImpactReference; approved-payment charge finalization now checks regional-benefit summary columns against frozen impact rows before lifecycle advancement. Payment-change requested amount authority now also carries RegionalBenefitChargeImpactAcknowledgement, so stale finalized-charge snapshots or missing frozen impact line ids are rejected before accepting mother-visible adjustment amounts. Remaining work: reservation entrypoints must resolve that decision from catalog/address data before workflow start, build_reservation_booking_workflow_request() must serialize the accepted decision into workflow input, and ServiceCalendarPolicy, payment conversion, branch settlement, and HQ settlement must consume the same frozen impact path instead of letting UI/admin locality labels choose behavior.

2026-07-07 Post-Booking Mutation Sidecar

Commits 7f7e061 and 87a3021 close the initial booking intake/runtime path for accepted service-term plans. Source still mutates service-period facts after booking through admin/customer flows. Modern target is one backend-owned ServiceTermPlan -> ReservationServiceOccurrenceLedger revision path with expected revision, actor/reason, source evidence key, and consumer invalidation.

Source mutation evidence	Modern target behavior
Admin detail save accepts service start/end/term, selected Saturdays, selected holidays, payment dates, status, address, and memo in one form, then updates service rows and logs a broad diff: source-refs/sanmopia-admin/static/js/reservation_status/reservation_detail.js:271-338, source-refs/sanmopia-admin/application/controllers/Reservation.php:676-695, :902-934, source-refs/sanmopia-admin/application/models/Reservation_model.php:1682-1711, :1785-1818.	ReservationServiceTermMutationCommand accepts a new backend-computed ServiceTermPlan, expected reservation/ledger revisions, mutation reason, and affected consumer list. If the revised plan changes service-area profile, the command requires frozen branch coverage evidence before writing a new occurrence ledger. OperatorServiceTermMutationDraft verifies operator source-form start/end/term/selected-date evidence against the backend plan and rejects broad-save status/payment fields into dedicated commands; POST /reservation-service-term-mutations/{reservationBookingId}/operator-draft-applications exposes that proof at the HTTP boundary. UI date fields, address strings, and string term labels are evidence only; pricing, care-team, refund, settlement, report, document, and entitlement projections must consume the new ledger key/revision.
Admin extra-day edit deletes all selected add dates and reinserts posted Saturday/holiday lists; end-date preview compares add-option quantities to saved date counts and warns on mismatch: source-refs/sanmopia-admin/application/controllers/Reservation.php:902-917, source-refs/sanmopia-admin/application/models/Reservation_model.php:4089-4139.	AdditionalServiceDaySelectionRevision must store a diffable selection revision, selected occurrence ids/dates, add-option quote linkage, and mismatch acknowledgement. Backend recomputes occurrence ledger and charge lines; UI cannot overwrite date arrays as authority.
Holiday add/modify/delete writes global holiday rows, while service-period recalculation reads current holiday rows when extending end date: source-refs/sanmopia-admin/application/controllers/ManageSystem.php:47-63, source-refs/sanmopia-admin/application/models/Manage_system_model.php:52-181, source-refs/sanmopia-admin/application/models/Reservation_model.php:5376-5418.	HolidayPolicyAffectedReservationReplan must publish a holiday-policy revision, find affected active/future ledgers, then either replan with compatibility decision or mark operator review required. Existing reservations must not silently read a changed holiday table.
Customer stop/change request only records request/status, while admin status changes reset coupons/payment/settlement side effects; reports infer stop/resume boundaries by string matching reservation change-log JSON: source-refs/sanmopia_web/application/models/Reservation_model.php:1068-1112, source-refs/sanmopia-admin/application/models/Reservation_model.php:1769-1916, source-refs/sanmopia_web/application/models/Report_model.php:312-349, :439-472, source-refs/sanmopia_web/application/models/Reservation_model.php:3261-3272.	ServiceSuspensionInterval must be a durable approved interval with resume boundary, affected occurrence ids, actual-service-day impact, benefit/coupon reset plan, refund/settlement impact, and report/export invalidation. Change-log string matching is source evidence only.
Extension creates a linked draft by cloning reservation facts and later checks the ancestor chain for voucher eligibility: source-refs/sanmopia_web/application/controllers/api/Reservation.php:243-289, source-refs/sanmopia_web/application/models/Reservation_model.php:2051-2233, :2473-2501.	ContinuationServiceTermPlanBinding must require accepted ServiceTermPlan and occurrence-ledger creation when the continuation draft is finalized, copying only audited immutable facts from the prior booking. Cloned source dates or service-day counts cannot be calendar authority.
Local benefit behavior is triggered by mutable address strings/options and changes both money and service duration: Yeongdeungpo discount reads address plus flag, Wanju adds days through option/string checks: source-refs/sanmopia-admin/application/controllers/Reservation.php:667-680, source-refs/sanmopia-admin/application/models/Reservation_model.php:714-729, source-refs/sanmopia-admin/application/models/Reservation_model.php:4089-4137, source-refs/sanmopia-admin/static/js/reservation_status/reservation_add.js:2176-2190.	RegionalBenefitServiceTermImpact must be recalculated from frozen address/coverage/catalog evidence whenever post-booking address or benefit selection changes. The same decision must update ServiceTermPlan, charge snapshot, refund requote, and settlement recognition; UI labels such as local district names are evidence only.
Status transition to settlement/payment closeout creates service-balance, manager-pay, and branch-settlement rows from current mutable reservation/payment data; payment-date save recalculates prices from current coupon/pre-reservation/local-benefit state; service-balance confirmation writes operator-entered amount directly: source-refs/sanmopia-admin/application/models/Reservation_model.php:1536-1679, :1802-1817, source-refs/sanmopia-admin/application/models/Reservation_model.php:3507-3555, source-refs/sanmopia-admin/static/js/reservation_status/reservation_detail.js:806-824, source-refs/sanmopia-admin/application/controllers/Reservation.php:1121-1130, source-refs/sanmopia-admin/application/models/Reservation_model.php:3667-3678.	PaymentCloseoutOccurrenceLedgerGuard requires finalized charge snapshot id and occurrence-ledger key/revision before service-balance closeout, manager payout projection, branch/HQ settlement opening, or repair commands run. Backend a414f59 adds PaymentCloseoutOccurrenceLedgerReference and requires branch/HQ settlement commands to acknowledge the frozen occurrence ledger key/revision when a closeout reference reader is configured. Backend 777b496 adds SupabasePaymentCloseoutOccurrenceLedgerReferenceReader and wires the production financial-lifecycle advancer to the existing sanmopia_reservation_service_occurrence_ledgers table, selecting the latest ledger revision for closeout checks. Backend 4e4b140 extends service-balance closeout itself so command/API/HTTP/Supabase RPC payloads must carry finalized_charge_snapshot_id, service_occurrence_ledger_key, and service_occurrence_ledger_revision_number; idempotency reuse now rejects stale closeout references. Backend follow-up supabase:smoke:stage:service-balance-closeout proves the stage DB path by saving a test reservation through sanmopia_save_reservation_booking_result, inserting a service occurrence ledger, closing service balance through sanmopia_save_service_balance_closeout, asserting event/current/receipt/reference rows, and rolling the transaction back. Backend follow-up supabase:smoke:stage:financial-lifecycle-closeout-guard now proves a real FastAPI/ReState stage booking can advance service delivery, caregiver payout, Branch settlement, HQ settlement, and settled only after the settlement command acknowledges the backend-confirmed closeout event; stale serviceBalanceCloseoutEventId is rejected. The proof also fixed the additional-service selection revision reader to consume field_changes from the actual journal table. 2026-07-08 backend follow-up: admin caregiver-payout projection rows now persist the closeout event id, finalized charge snapshot id, service-occurrence ledger key, and ledger revision from frozen service-balance closeout facts instead of exposing only mutable service-balance state. 2026-07-09 browser proof: family-assisted reservation RBQ-f7cc430a-0999-4788-a43e-d40832dfcf48 completed through the Astro card UI, produced booking 55ed4f0d-8cc6-40ff-9780-40fc31e7f30e, persisted a 10-occurrence service ledger, returned mother-visible charge summary 200, and closed service balance through sanmopia_save_service_balance_closeout with closeout event 156a9b7c-8393-41ad-9b98-c6124380ded1. Remaining work: concrete legacy caller binding, branch/HQ settlement projections reading only frozen closeout references, and operator UI without mutable service-date/local-benefit/add-option/UI-entered amount authority.

Mutation API Caller Inventory

These source routes are concrete future callers/adapters for the modern reservation service-term mutation endpoint. Preview/read routes should only quote a plan; save/approval routes must carry expected ledger revision, actor/reason, and source evidence.

Source route	Evidence refs	Modern target behavior
POST /reservation/saveReservationData	source-refs/sanmopia-admin/static/js/reservation_status/reservation_detail.js:271-338, source-refs/sanmopia-admin/application/controllers/Reservation.php:676-695, :902-934, source-refs/sanmopia-admin/application/models/Reservation_model.php:1785-1818	Admin service date, term, address, and add-day edits first pass through POST /reservation-service-term-mutations/{reservationBookingId}/operator-draft-applications, which accepts source fields only as evidence against a backend-owned ServiceTermPlan; status/payment side effects split to reservation-state and financial lifecycle commands.
POST /reservation/savePreReservationData	source-refs/sanmopia-admin/static/js/reservation_status/pre_reservation_detail.js:299-328, source-refs/sanmopia-admin/application/controllers/Reservation.php:1024-1089	Pre-reservation activation of service start/end dates creates or revises the backend service-term plan and ledger instead of deriving occurrence authority from form save side effects.
POST /reservation/insertAddService; POST /reservation/deleteService	source-refs/sanmopia-admin/application/controllers/Reservation.php:514-534, source-refs/sanmopia-admin/application/models/Service_model.php:71-103, :148-181, :190-260	Additional Saturday/holiday option quantity edits create AdditionalServiceOptionSelectionRevision; deletion must not erase selected occurrence dates except through ReservationServiceTermMutationCommand. Service-balance amount changes from add-option rows must flow through charge snapshot and closeout ledger guard.
POST /api/reservation/inputServiceStartDate; POST /api/reservation/inputDeliveryData	source-refs/sanmopia_web/application/controllers/api/Reservation.php:53-83, :345-416, source-refs/sanmopia_web/static/js/mypage/reservation.js:154-178, :250-286	Customer-provided service start changes become customer-scoped service-term mutation requests with ownership proof, expected revision, and backend recomputation; UI delivery fields are evidence only.
POST /api/reservation/request/{stop,change} plus admin approval through POST /reservation/saveReservationData	source-refs/sanmopia_web/static/js/mypage/reservation.js:326-374, source-refs/sanmopia_web/application/models/Reservation_model.php:1068-1112, source-refs/sanmopia-admin/application/models/Reservation_model.php:1769-1916	Stop/resume and change approvals create ServiceSuspensionInterval plus service-term mutation and occurrence-ledger revision; customer request rows are not the calendar authority.
POST /api/reservation/processContinue	source-refs/sanmopia_web/static/js/mypage/reservation.js:425-436, source-refs/sanmopia_web/application/controllers/api/Reservation.php:243-289, source-refs/sanmopia_web/application/models/Reservation_model.php:2051-2233	Continuation finalization binds a new accepted ServiceTermPlan and occurrence ledger through ContinuationServiceTermPlanBinding; later continuation date edits use the mutation endpoint.
POST /service/insertYeongdeungpoFl	source-refs/sanmopia_web/static/js/step3_voucher.js:367-383, source-refs/sanmopia_web/application/controllers/Service.php:692-701, source-refs/sanmopia_web/application/models/Reservation_model.php:2839-2852	Address/local-benefit changes use RegionalBenefitServiceTermImpact to recalculate service duration, charge snapshot, refund basis, and settlement facts through backend evidence.
POST /manageSystem/editHoliday	source-refs/sanmopia-admin/static/js/manage_system/holiday_list.js:41, :88, source-refs/sanmopia-admin/application/controllers/ManageSystem.php:43-68, source-refs/sanmopia-admin/application/models/Manage_system_model.php:52-181	Holiday policy execution publishes HolidayPolicyAffectedReservationReplan; affected reservations then receive service-term mutation/review decisions instead of silently reading a changed holiday table.
POST /reservation/confirmServiceBalance	source-refs/sanmopia-admin/static/js/reservation_status/reservation_detail.js:806-824, source-refs/sanmopia-admin/application/controllers/Reservation.php:1121-1130, source-refs/sanmopia-admin/application/models/Reservation_model.php:3667-3678	Service-balance confirmation must submit a finalized charge snapshot id plus acknowledged occurrence ledger key/revision. UI-entered service-balance amount is evidence only and cannot open/confirm settlement by itself.
Preview only: POST /reservation/getEndDate, POST /reservation/newReservationGetEndDateCalc, POST /api/reservation/getServiceExpectEndDate, GET /api/reservation/getSaturdayAndHoliday/{startDate}	source-refs/sanmopia-admin/static/js/reservation_status/reservation_detail.js:172-190, source-refs/sanmopia-admin/static/js/reservation_status/reservation_add.js:2155-2196, source-refs/sanmopia_web/static/js/step3.js:861-899, :1091-1105, source-refs/sanmopia_web/application/controllers/api/Reservation.php:292-341	These become backend service-term quote/read APIs only; writes still happen through save/approval routes with expected ledger revision and mutation reason.

Checklist Mapping

Existing checklist rows already cover overlapping foundations:

• source-feature-checklist.md reservation lifecycle service-calendar rows: versioned service period planning, holiday policy, extra Saturday/holiday days, and immutable calendar snapshots.
• source-feature-checklist.md system holiday rows: global holiday source evidence and remaining command/API/UI gaps for holiday policy publication.
• source-feature-checklist.md refund/payment rows: refund quote, payment-refund intent, partial refund, payment adjustment catalog, discount adjustment, additional charge adjustment, and payment product plan foundations.

The follow-up dig promoted ServiceSuspension, BranchCoveragePolicy, ReservationExtensionPlan, and ReservationPromotionSideEffectPlan into separate checklist owners because legacy source stores those side effects in status logs, copied reservations, address matching fallbacks, and coupon/payment controller paths.

2026-07-05 Persistent Worker Addendum

• Bind holiday decisions to execution. Status: Partial. Evidence: source-refs/sanmopia-admin/application/models/Manage_system_model.php:52-181, source-refs/sanmopia-admin/application/controllers/ManageSystem.php:43-69, source-refs/sanmopia-admin/application/controllers/ajax/ManageSystem.php:14-32, and source-refs/sanmopia-admin/static/js/manage_system/holiday_list.js:1-107. Source behavior: operators add, modify, and delete HOLIDAY_TB rows from free-text form data, while calendar consumers receive only date strings. Modern gap: HolidayPolicyExecution must apply accepted decisions with expected revision, actor, source/import authority, duplicate-date result, substitute-of relation, supersession, branch/company scope, and invalidation fanout for quote, matching, report, refund, and settlement readers.

• Freeze extension and continuation compatibility facts. Status: Partial. Evidence: source-refs/sanmopia_web/application/models/Reservation_model.php:2038-2233, source-refs/sanmopia_web/application/models/Reservation_model.php:2466-2502, source-refs/sanmopia_web/application/controllers/api/Reservation.php:243-290, and source-refs/sanmopia_web/static/js/mypage/reservation.js:424-464. Source behavior: a continuation copies selected reservation facts, replaces existing continue links, checks voucher eligibility by walking the source chain, and redirects the customer by canVoucher. Modern gap: ReservationContinuationLink needs copied-fact audit rows, branch coverage decision evidence, service-calendar compatibility decision, same-caregiver availability, voucher-chain decision, and impacted pricing/matching/settlement invalidation.

• Move local benefit/service-day bonus binding behind backend profile data. Status: Partial. Evidence: source-refs/sanmopia_web/application/models/Reservation_model.php:2526-2612, source-refs/sanmopia-admin/application/controllers/Reservation.php:1740-1758, source-refs/sanmopia-admin/application/models/Reservation_model.php:5376-5418, source-refs/sanmopia-admin/static/js/reservation_status/reservation_add.js:927-948, source-refs/sanmopia-admin/static/js/reservation_status/reservation_add.js:1518-1542, and source-refs/sanmopia-admin/application/views/reservation_status/reservation_add.php:273-303. Source behavior: customer and admin paths apply locality support with different duration math, and admin UI constructs support item payloads. Modern gap: ResidencySupportProfile / RegionalBenefitDecision must be resolved from address/catalog evidence before booking workflow start, then read by ServiceCalendarPolicy, payment conversion, settlement participation, and charge snapshot creation.

2026-07-10 Service-Unit Source Refresh

No new checklist ids. These anchors refine existing owners: ServiceCalendarPolicy, ReservationContinuationLink, ServiceSuspensionRequest, ActualServiceProductCouponEntitlement, ServiceAreaCoverageDecision, and CaregiverCandidateOrderingPolicy.

• Weekly service abstraction and compatibility mode. Status: Partial. Evidence: source-refs/sanmopia_web/application/models/Reservation_model.php:463-485 converts voucher service days into seven-day spans and shifts weekend end dates backward, while source-refs/sanmopia_web/application/models/Reservation_model.php:2519-2626 treats weekly input as five service days, skips Sundays/Saturdays/system holidays, and extends the boundary to selected Saturday/holiday additions. Backend rule: migrated reservations need a frozen ServiceCalendarCompatibilityDecision; new reservations must use one profile-backed service-week policy, not controller-specific math.

• Extra Saturday, holiday, and substitute-holiday behavior. Status: Partial. Evidence: source-refs/sanmopia_web/application/models/Reservation_model.php:2709-2764 separates non-holiday Saturdays from HOLIDAY_TB dates and persists selected added dates as SAT or HOLI, while source-refs/sanmopia-admin/application/controllers/Reservation.php:692-695 and source-refs/sanmopia-admin/application/controllers/Reservation.php:902-917 accept posted Saturday/holiday arrays and rewrite reservation added-date rows. Backend rule: selected added dates are occurrence facts with reason, price impact, caregiver assignment impact, and settlement impact. Substitute holiday meaning still must come from HolidayPolicyVersion, not free-text holiday labels or date membership alone.

• Extension, pause/resume, and coupon timing. Status: Partial/Pending. Evidence: source-refs/sanmopia_web/application/controllers/api/Service.php:296-451 handles continuation eligibility, voucher-extension rejection, same-caregiver continuation attempt, and continuation status routing; source-refs/sanmopia-admin/application/controllers/Reservation.php:632-639 includes stopped reservations on the calendar; source-refs/sanmopia-admin/application/models/Coupon_model.php:33-157 recalculates product coupons from actual attendance count on stop/cancel; and source-refs/sanmopia-admin/application/models/Coupon_model.php:212-324 issues normal-service product coupons with start+3/start+8 publication timing by service term and working type. Backend rule: continuation, stop/resume, and coupon issuance consume the same service occurrence/attendance ledger and emit invalidation facts for refund, payout, branch/HQ settlement, and archive projections.

• Region coverage and matching day-window effects. Status: Partial. Evidence: source-refs/sanmopia_web/application/models/Branch_model.php:38-140 matches branch coverage by address levels, special split ADDRESS_LEVEL_2 tokens, and impossible-area veto; source-refs/sanmopia_web/application/models/Manager_matching_model.php:166-228 ranks candidates by preference/personality score, branch, manager class, and MANAGER_SCHEDULE_CHECK_FN over service start/end; source-refs/sanmopia_web/application/models/Manager_matching_model.php:248-324 calculates and sorts by coordinate distance; and source-refs/sanmopia-admin/application/models/Matching_model.php:724-862 computes ODSAY travel time but still sorts by score. Backend rule: ServiceAreaCoverageDecision and CaregiverCandidateOrderingPolicy must consume frozen service dates/day-count profile, coverage profile, class eligibility, distance/travel evidence freshness, and fallback reason before assignment or settlement-facing projections.

2026-07-10 Service-Unit Implementation Fact Refinement

No new checklist ids. This refines backend fact shape for the existing service-unit owners only.

• ServiceOccurrenceLedger materialization cause. Status: Partial. Evidence: source-refs/sanmopia_web/application/models/Payment_model.php:140-151 validates and marks coupons during downpayment closeout, then source-refs/sanmopia_web/application/models/Payment_model.php:154-280 inserts payment rows, points/shoppingmall coupon compensation, and calls RESERVATION_DATE_INSERT_FN; source-refs/sanmopia_web/application/controllers/api/Payment.php:160-180 wraps that local write in provider-refund fallback on failure; source-refs/sanmopia_web/application/models/Reservation_model.php:488-511 and source-refs/sanmopia_web/application/models/Reservation_model.php:536-540 call the same routine from voucher insert/update; source-refs/sanmopia_web/application/models/Reservation_model.php:3169-3173 and source-refs/sanmopia_web/application/controllers/api/Reservation.php:439-444 call it after birth/start-date edits; admin flows call it from source-refs/sanmopia-admin/application/controllers/Reservation.php:1080-1088, source-refs/sanmopia-admin/application/models/Reservation_model.php:2017, and source-refs/sanmopia-admin/application/models/Reservation_model.php:5196. Backend fact gap: the ledger command needs source-attributed cause (payment_closeout, service_period_change, delivery_start_change, or admin_repair), actor, expected reservation revision, service-period revision, payment/provider event id when present, policy fingerprint, idempotency key, and resulting ledger revision before settlement, report, coupon, or payout readiness changes.

• HolidayPolicyVersion execution facts. Status: Partial. Evidence: source-refs/sanmopia-admin/static/js/manage_system/holiday_list.js:18-107 drives add/modify/delete with client data-type and posted free-text holiday type/date; source-refs/sanmopia-admin/application/controllers/ManageSystem.php:43-68 switches on posted fedit-type; source-refs/sanmopia-admin/application/models/Manage_system_model.php:52-108 creates free-text holiday types and rejects duplicate dates; source-refs/sanmopia-admin/application/models/Manage_system_model.php:111-162 mutates the holiday type for the same date key; and source-refs/sanmopia-admin/application/models/Manage_system_model.php:165-181 deletes the date row. Calendar reads expose only dates through source-refs/sanmopia-admin/application/controllers/ajax/ManageSystem.php:16-31. Backend fact gap: accepted holiday decisions need action, actor, effective date, typed holiday kind, source/provider kind, duplicate-date decision, substitute-of relation, supersession link, announcement timestamp, impacted reservation ids, and whether each impact requires quote, assignment, occurrence-ledger, refund, or settlement invalidation.

• ServiceSuspensionRequest and report occurrence effects. Status: Partial/Pending. Evidence: source-refs/sanmopia_web/application/controllers/api/Reservation.php:86-205 accepts customer stop requests, sends branch notifications, and has a branch-specific duplicate notification edge; source-refs/sanmopia_web/application/models/Reservation_model.php:1091-1111 stores only stop status plus request content; report selection later infers stop intervals from RESERVATION_CHANGE_LOG status JSON in source-refs/sanmopia_web/application/models/Report_model.php:312-350 and source-refs/sanmopia_web/application/models/Report_model.php:439-478, then marks every fifth service occurrence, end date, and stop-start date in source-refs/sanmopia_web/application/models/Report_model.php:352-391 and source-refs/sanmopia_web/application/models/Report_model.php:480-518. Backend fact gap: suspension needs request/approval/resume facts with actor, reason, effective interval, notification targets, branch override, linked occurrence-ledger revision, daily-report cutoff dates, and financial invalidation reasons instead of reconstructing service intervals from text status-change logs.

• ActualServiceProductCouponEntitlement grant and visibility facts. Status: Partial. Evidence: source-refs/sanmopia-admin/application/models/Coupon_model.php:250-324 issues hardcoded product coupons by service term and working type (PRODUCT1/PRODUCT2, 20000/30000, service-start +3 or +8 days); source-refs/sanmopia-admin/application/models/Coupon_model.php:588-695 converts coupon rows into operator-visible status/usage/price labels; source-refs/sanmopia-admin/application/models/Coupon_model.php:888-930 lets an operator immediately grant one-week/two-week product coupons or mark no-issue, creating a user coupon with six-month expiry; and source-refs/sanmopia_web/application/models/Coupon_model.php:184-240 plus source-refs/sanmopia_web/application/models/Coupon_model.php:241-268 makes customer use depend on publish time and USE_FL. Backend fact gap: entitlement must be one backend-owned decision over credited service occurrences, actual attendance, interruption kind, continuation/source reservation, working type, settlement recognition period, operator override, user-grant expiry, visibility status, and notification outbox event. UI must render these facts, not recalculate status labels or benefit amount.

• CaregiverCandidateOrderingPolicy schedule/distance surface split. Status: Partial. Evidence: source-refs/sanmopia-admin/application/models/Matching_model.php:44-124 ranks by preference/personality score, schedule function, pet exclusion, optional branch/class/search filters, random tie, and then distance sort; source-refs/sanmopia-admin/application/models/Matching_model.php:724-758 uses a separate admin recommendation query with branch/class filters and score/random order; source-refs/sanmopia-admin/application/models/Matching_model.php:766-862 fetches or calls ODSAY travel time but still sorts by score; and source-refs/sanmopia_web/application/models/Manager_matching_model.php:73-151 plus source-refs/sanmopia_web/application/models/Manager_matching_model.php:248-307 persists travel-time cache on the customer surface and computes coordinate distance. Backend fact gap: recommendation sets must capture source surface, service start/end window, schedule proof, branch/class/search filters, pet exclusion, candidate limit, score components, random/tie seed, distance and travel evidence freshness/fallback, and the final ordered reason so assignment, payout, and settlement projections do not depend on whichever UI/controller path ranked first.