Source Feature Checklist

This checklist is source-first. A feature is not complete until contract, backend, frontend, Supabase, docs, and tests prove the modern replacement.

Source UI logic is migration evidence, not frontend behavior to preserve. Any source view, JavaScript, or controller path that sums money, derives status, chooses buttons, validates download readiness, or decides actor visibility must move into backend domain policy, application commands, or versioned read models. Modern frontend surfaces may render only backend-computed projections and submit explicit commands; they must not recompute totals or infer workflow state from raw rows, source status ids, payment maps, document tokens, or storage refs. Frontend repository architecture is atomic/static-view first, not DDD feature slice. Any frontend src/features/** directory is migration debt unless it is pure route/view composition with no policy, money math, settlement logic, matching logic, RBAC, audit, lifecycle transition, or Supabase authority. Shared UI state must use Nanostores and generated contracts; durable decisions belong to backend domain/application slices, SpiceDB/OPA/ReState gates, and Supabase ledger/read models. For reservation/payment/settlement flows, e2e_proven means the browser path used backend-owned projections, commands, SpiceDB grants, Supabase/RLS reads, and frozen financial facts. A passing browser scenario that still depends on src/features/**, UI-side amount math, UI-side status mapping, local RBAC, or mutable source-row interpretation stays runtime_wired at most.

Architecture and feature flow diagrams live in C4 Model. Checklist items should link back to that page when a source feature changes Context, Container, Component, or Code-level design.

Folder architecture audits: DDD Domain Folder Audit, DDD Application Contract Folder Audit, Legacy UI Business Logic Gap Mining, and Code Health Debt Map track naming, CQRS, boundary, and backend-projection debt found by CaveCrew.

Focused source-mining pages: Admin Analytics And System Gap Mining, Caregiver Matching Assignment Gap Mining, Branch Office Operations Gap Mining, Document Reporting Gap Mining, Customer Engagement Commerce Gap Mining, Notification And Document Delivery Gap Mining, Promotion Caregiver Analytics Gap Mining, Settlement Data Room Gap Mining, Partner Benefit Fulfillment Gap Mining, Customer Self-Service Workspace Gap Mining, Manager And Customer Portal Gap Mining, Operator Backend Decision Gap Mining, Status Payment Settlement Source Map, and Reservation Lifecycle Side Effect Execution. Family Authority, Payment, And Privacy Gap Mining tracks sponsor consent, delegated payer, historical authority, care-history, and financial visibility boundaries. UI-side business-rule gaps are tracked in Legacy UI Business Logic Gap Mining. Traffic-spike protection is tracked in Traffic Spike Backpressure Gap Mining. Runtime telemetry rules are tracked in Observability and Backpressure.

Status tags:

Migrated: replacement exists and is verified.
Partial: modern slice exists, but source coverage or runtime workflow remains incomplete.
Pending: source feature identified, no full modern replacement yet.

Machine-countable SFC rows use these statuses for new rows and touched rows:

pending: source gap only.
mapped: source evidence plus DDD target named.
foundation: domain/application/contract tested.
runtime_wired: persistence, API, worker, or access control bound.
e2e_proven: runtime path exercised end to end.
migrated: legacy/UI authority removed or disabled.
blocked: owner and unblock condition named.

Canonical row schema:

feature_id	lane_owner	source_evidence	ddd_aggregate	command_query	persistence	contract	e2e_proof	status

Delegation Control Notes

Frontend work may use native bounded delegation. Main migration control owns backend, contracts, source evidence, docs, and PR review. Frontend must not reintroduce UI-side price, settlement, status, or region-label mapping.
Delegation uses native bounded subtasks. Do not maintain persistent agent ids, resume stale workers, or keep an agent registry in product documentation. Controller supplies checklist/ADR context with each task, reviews uploaded changes, then lets the worker terminate.

Workstream ownership describes repository boundaries, not agent identity:

Workstream	Owner boundary	Delegation rule	Expected output
Hidden legacy feature mining and documentation	Source evidence lane	One read-only bounded source slice per native delegation. Never repeat already documented mining.	Gap rows with source path and line range, legacy behavior, modern target name, bounded context, feature slice, backend policy/contract need, and status.
Frontend implementation	`frontend-repo` Atomic UI lane	Delegate disjoint production paths; controller owns bounded Playwright execution and process cleanup.	Atomic-pattern UI consuming generated contracts, NanoStores presentation state, and no frontend `src/features/**` business logic.
Backend and contract implementation	Backend/contract feature lane	Delegate only disjoint feature-level write sets; controller reviews architecture, migrations, and public compatibility.	Domain policy, application contract, Supabase migration, colocated tests, Tach/Vulture gates, and generated contracts.
Migration governance and integration	Main migration control	Never delegate final merge, stage mutation, E2E, process cleanup, progress accounting, or ADR/checklist truth.	Reviewed commits, live stage evidence, bounded E2E, and Starlight documentation.

Delegated workers must not launch Playwright or long-lived Serena/Tach MCP processes. Controller performs semantic review and browser proof. A worker is terminated immediately when resource limits or repository ownership are violated; its file changes remain subject to normal review.
Backend shared-kernel now owns stable identity predicates used by service calendar, service period, service commitment, and customer action availability slices. Bounded contexts still raise their own domain errors; duplicated lower-code/reference predicates should continue moving to shared_kernel / stable_identity only when focused tests cover the slice.
2026-07-05 follow-up: caregiver matching, caregiver matching profile, care team contract, and assignment optimizer inputs now reuse shared_kernel / stable_identity for stable code predicates instead of local regex copies.
2026-07-05 follow-up: payment refund and cancellation adjustment catalog code validation now also uses shared_kernel / stable_identity, keeping refund-domain errors local while removing another regex copy.
2026-07-05 follow-up: member privacy withdrawal lifecycle and repair-history reason/status/actor code validation now also use shared_kernel / stable_identity; privacy-domain errors remain local, while code-shape rules stay shared.
2026-07-05 follow-up: service-calendar holiday audit actor, provider, and reason code validation now also uses shared_kernel / stable_identity; holiday-audit reference and fingerprint checks remain local to that slice.
2026-07-05 follow-up: daily-care-report field, section, option, definition, and reward reason code validation now also uses shared_kernel / stable_identity; report label checks remain local because they allow dotted display/catalog labels.
2026-07-05 follow-up: document room, document delivery, branch resource post, branch office content, and offline reservation intake code validation now also use shared_kernel / stable_identity; reservation change request keeps its local predicate because Tach explicitly blocks that feature from depending on domain.shared_kernel.
2026-07-05 follow-up: reservation payment workflow action values now live in the application payment workflow slice and are reused by Kill Bill ingestion and Supabase workflow row hydration, removing adapter-local action sets.
2026-07-05 follow-up: service calendar now preserves explicit substitute holiday source-date relation, applies rollback end-date policy as calendar span then rolls back to a service day, and service commitment tests cover selected extra days plus pause-suppressed coupon obligations.
2026-07-05 follow-up: caregiver credential dossier stable code validation now uses shared_kernel / stable_identity; opaque storage/object ids remain local because they allow a wider character set than business codes.
2026-07-06 follow-up: customer reservation lifecycle view and reservation actor capability projection now reuse shared_kernel / stable_identity for dotted stable codes instead of local regex constants.
Regional benefit lines now require backend/contract-provided amount-source labels (amount_component_label / amountSourceLabel) so frontend pricing views render catalog-owned labels instead of mapping amount-source keys. Supabase catalog policy adds amount_source_label for source-amount rules.
Regional benefit profile metadata now belongs to backend policy data: regional_benefit_profile_key, service_day_bonus_count, and settlement_participation_code on RegionalBenefitRule. FinalizeReservationChargeWithRegionalBenefitHandler now resolves a backend-owned RegionalBenefitDecision before building ReservationPriceSummaryInput and charge snapshot evidence. HTTP/API request models accept an acceptedRegionalBenefitDecision, Restate payload decoding can hydrate it, and charge finalization preserves profile/service-day/ settlement metadata. Remaining work: reservation entrypoints still must resolve the decision from catalog/address data before workflow start, build_reservation_booking_workflow_request() still must serialize the accepted decision into the workflow input payload, and service-calendar impact, payment-conversion, and settlement consumers still need to call/read the same frozen decision path.
Notification obligation dispatch no longer exposes domain enum/action state through UI-shaped api_shape() from domain. Stringification belongs in the application contract boundary.
Supabase CLI is available through pnpm exec supabase; local DB lint was attempted but local Postgres was not reachable, so type regeneration must run after the stage/local Supabase DB has the new migration applied.
Supabase stage migration replay is green through 20260705171000_customer_reservation_request_workflows.sql. The 2026-07-05 replay fix shortened reservation lifecycle side-effect evidence constraint names to avoid PostgreSQL identifier truncation collisions, and preserved existing customer-inquiry/caregiver-office trigger codes when extending the communication workflow catalog constraint.
2026-07-07 booking workflow smoke is green through backend supabase:smoke:stage:reservation-booking: stage FastAPI accepts a real branch-operator booking request, Restate completes it, the progress endpoint returns the completed reservation, and the workflow row preserves the branch actor instead of overwriting requested_by_user_id with the mother user.
2026-07-08 reservation scenario loop is now stage-smokeable beyond booking: supabase:smoke:stage:payment-continuation-after-service-delivery creates a booking, starts a paid payment workflow, observes waiting_for_financial_facts while service delivery is missing, records service delivery, prepares caregiver payout, branch settlement, and HQ settlement ledger facts with frozen closeout references, then proves the same payment workflow row starts settlement continuation instead of staying blocked on stale financial-fact state.
2026-07-13 callback-to-settlement e2e is green on stage: pnpm supabase:smoke:stage:killbill-callback-to-settlement-completion creates a reservation, ingests synthetic Kill Bill PAYMENT_SUCCESS, records service delivery, creates caregiver payout instruction, records branch payout deposit acknowledgement and caregiver payout receipt acknowledgement, prepares branch/HQ settlement through backend HTTP commands, starts settlement continuation, completes settlement, refreshes operator settlement boards, and reaps test data. This promoted caregiver payout receipt from a receipt-state projection only to a guard-visible CaregiverPayoutAcknowledgement command.
2026-07-13 follow-up: the same smoke now records caregiver payout receipt as the assigned caregiver actor. Backend resolves payout target profile id to the frozen assigned_caregiver_user_id, requires SpiceDB booking view permission, and still writes the acknowledgement against the payout instruction target expected by settlement-continuation guards.
2026-07-13 projection follow-up: the caregiver receipt acknowledgement command now also writes the acknowledged receipt-state projection consumed by caregiver/operator UX. The same stage smoke now asserts caregiver_payout_receipt_state=acknowledged and reaps receipt-state events before payout instructions, preventing test-data cleanup from hiding FK debt.
2026-07-08 RBAC hardening follow-up re-ran supabase:smoke:stage:financial-lifecycle-closeout-guard after removing Supabase app_metadata role/profile authority. Stage created reservation f3423929-ad23-4129-a4b4-8f2f74d1f265 and service-balance closeout event ad2d90f2-4b61-46bd-af7d-5a7218e0a296, then advanced the financial lifecycle through branch/HQ settlement completion under backend/SpiceDB authority.

Newly Confirmed Unclosed Gaps

Gap	Legacy evidence	Modern owner	Required migration
Cancellation side effects	`source-refs/sanmopia-admin/application/config/constants.php:116`, `source-refs/sanmopia_web/application/models/Reservation_model.php:989`	`reservation_operations / ReservationLifecycleCommand`, `pricing_settlement / CancellationRefundLifecycle`	Status transition, instant refund, coupon restore, Momfirst unlink, side-effect outbox, and refund/coupon ordering must be backend-owned.
Weekly/extension/weekend/holiday service	`source-refs/sanmopia-admin/application/views/reservation_status/reservation_detail.php:778`, `source-refs/sanmopia-admin/application/models/Manage_system_model.php:51`	`reservation_operations / ServicePeriodPlan`, `service_calendar / HolidayPolicyExecutionAndImpactInvalidation`	Freeze service occurrences, holiday revisions, substitute holidays, quote/matching/report/refund/settlement invalidations, and branch-specific closure evidence.
Settlement data room and HQ/Danbee/inter-office settlement	`source-refs/sanmopia-admin/application/controllers/Calculate.php:151`, `source-refs/sanmopia-admin/application/controllers/DataRoom.php:218`	`pricing_settlement / SettlementActionJournal`, `SettlementStatementWorkflow`, `SettlementDataRoomArtifactRequest`	Separate HQ request, branch confirmation, Danbee settlement, inter-office confirmation, export revision, signed grants, repair audit, and actor-scoped transition journal.
Custom adjustment and negative lines	`source-refs/sanmopia-admin/application/views/modal/modal_other_service_add.php:18`, `source-refs/sanmopia-admin/application/controllers/Calculate.php:184`	`pricing_settlement / SettlementManualAdjustmentLine`	Versioned adjustment catalog, signed amount direction, reason, actor, statement linkage, and no freeform browser line math.
Payment change, refund, partial refund	`source-refs/sanmopia_web/application/views/modal/modal_change_payment.php:3`, `source-refs/sanmopia_web/application/models/Payment_model.php:383`, `source-refs/sanmopia_web/application/libraries/Kcppayment.php:39`	`pricing_settlement / PaymentChangeAdjustmentAmountBreakdown`, `PaymentRefundIntent`	Freeze delta, provider context, refund quote, partial-cancel event, ledger reversal, receipt artifact, and Kill Bill-backed provider orchestration.
Caregiver matching evidence	`source-refs/sanmopia-admin/application/models/Matching_model.php:44`, `source-refs/sanmopia-admin/application/models/Matching_model.php:724`	`caregiver_assignment / CaregiverCandidateOrderingPolicy`	Freeze score components, distance/travel freshness, schedule, pet, grade/class, branch scope, and deterministic tie-breaker evidence.
Multi-caregiver payroll	`source-refs/sanmopia-admin/application/views/reservation_status/reservation_detail.php:45`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:2166`, `source-refs/sanmopia-manager/application/helpers/salary_helper.php:8`	`caregiver_assignment / CareTeamRosterAssignmentDecision`, `pricing_settlement / CaregiverPayoutPolicyProfile`	Persist role slots, assignment terms, payout snapshots, tax election, custom pay audit, and prevent salary evidence deletion.
Family, delegated payer, authority	`source-refs/sanmopia_web/application/views/service/step1.php:188`, `source-refs/sanmopia_web/application/controllers/api/Service.php:70`	`member_management / ReservationPartyAuthoritySnapshot`	Separate mother, sponsor, payer, emergency contact, contact-only viewer, refund recipient, document viewer, and delegation validity windows.
Service-area profile	`source-refs/sanmopia-admin/application/models/Branch_model.php:289`, `source-refs/sanmopia-admin/application/models/Branch_model.php:345`	`branch_operations / ServiceAreaDecisionSnapshot`	Effective-dated coverage profiles, address normalization, serviceability/counsel/impossible evidence, and booking-bound snapshots.
Branch/HQ conflict and audit	`source-refs/sanmopia-admin/application/controllers/Reservation.php:651`, `source-refs/sanmopia-admin/application/controllers/Reservation.php:821`	`reservation_operations / ReservationCollaborationCommand`, `operator_access / ActorStageCapabilityProjection`	Typed commands, expected revision, conflict diff, selected winner, actor capability snapshot, and append-only journal before any broad save.

2026-07-05 Persistent Worker Legacy Mining Delta

This pass narrows backend-owned gaps still visible in legacy PHP/JS sources. Source paths are evidence only; the target must be policy, command, or read-model authority.

Priority	Gap	Legacy evidence	Modern owner	Required migration
P0	Service duration, holiday, extension, and local-support parity	`source-refs/sanmopia_web/application/models/Reservation_model.php:463-486`, `source-refs/sanmopia_web/application/models/Reservation_model.php:2038-2233`, `source-refs/sanmopia_web/application/models/Reservation_model.php:2515-2630`, `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/application/models/Manage_system_model.php:52-181`, `source-refs/sanmopia-admin/static/js/manage_system/holiday_list.js:1-107`	`service_calendar / ServiceCalendarCompatibilityDecision`, `HolidayPolicyExecution`, `reservation_operations / ReservationContinuationLink`, `pricing_settlement / RegionalBenefitDecision`	Execute accepted holiday add/revise/withdraw decisions with version, scope, supersession, and audit; freeze which legacy service-end mode produced historical rows; bind extension/copy facts, branch coverage, same-caregiver availability, and local support bonus from backend decisions instead of UI locality flags.
P0	Charge, discount, support-item, and custom amount hardcoding	`source-refs/sanmopia_web/static/js/step3.js:198-560`, `source-refs/sanmopia_web/static/js/step3.js:766-831`, `source-refs/sanmopia_web/application/views/reservation/retc.php:1-205`, `source-refs/sanmopia-admin/application/views/reservation_status/pre_reservation_price_table.php:1-124`, `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`, `source-refs/sanmopia-admin/application/config/constants.php:112-113`, `source-refs/sanmopia-user-old/src/data/mock/reservation.ts:395-419`, `source-refs/sanmopia-user-old/src/data/mock/reservation.ts:468-490`, `source-refs/sanmopia-user-old/src/data/mock/reservation.ts:612-644`, `source-refs/sanmopia-user-old/src/data/mock/reservation.ts:936-985`	`pricing_settlement / ReservationChargeLineCatalogProjection`, `PaymentProductPlanTemplate`, `PaymentAdjustmentCatalog`, `PreReservationCreditPolicy`, `RegionalBenefitRule`	Move delivery fee, pre-reservation credit, in-home/special voucher add-on display, weekend/holiday add-day pricing, regional discount, local support item ids/names, deposit/balance split, service-balance zero/positive cases, payment-product labels/statuses, and all display labels into backend catalog snapshots. UI and smoke/demo fixtures may only render catalog-issued frozen charge/payment templates and submit explicit adjustment commands; they must not copy TypeScript mock totals, Korean payment labels, provider refs, or hardcoded `PRERESERVATION_PRICE` into booking/payment fixtures.
P0	Settlement data-room worklist and export workflow	`source-refs/sanmopia-admin/application/controllers/DataRoom.php:30-94`, `source-refs/sanmopia-admin/application/controllers/DataRoom.php:218-250`, `source-refs/sanmopia-admin/application/controllers/DataRoom.php:268-386`, `source-refs/sanmopia-admin/application/controllers/ajax/DataRoom.php:17-240`, `source-refs/sanmopia-admin/static/js/data_room/form_reservation_list.js:1-260`, `source-refs/sanmopia-admin/application/views/table/data_room/table_calculate_central.php:1-69`, `source-refs/sanmopia-admin/application/views/table/data_room/table_calculate_danvi.php:1-57`	`document_reporting / ReservationDocumentExportWorklist`, `pricing_settlement / SettlementDataRoomArtifactRequest`, `SettlementDataRoomCollectionExportReader`	Replace PHP-memory filtering, URL hash filters, hidden iframe downloads, raw GET export parameters, and controller document-id switches with database-backed worklists, immutable selection tokens, bundle policy versions, artifact build records, signed grants, return-state tokens, and action audit.
P0	Family, proxy payer, contact, refund, and document authority	`source-refs/sanmopia_web/application/views/service/step1.php:91-213`, `source-refs/sanmopia_web/application/models/Reservation_model.php:314-374`, `source-refs/sanmopia_web/application/controllers/api/Service.php:67-83`, `source-refs/sanmopia_web/application/controllers/api/Payment.php:89-113`, `source-refs/sanmopia_web/application/models/Payment_model.php:570-704`	`member_management / ReservationPartyAuthoritySnapshot`, `pricing_settlement / PayerSnapshot`, `document_reporting / DocumentRecipientAuthority`	Separate mother, booker, payer, family sponsor, emergency-contact-only recipient, refund recipient, document viewer, and notification recipient. Relation text, phone numbers, reservation owner checks, and branch notice hardcoding are migration evidence, not modern authority.
P0	Branch coverage and address profile binding	`source-refs/sanmopia_web/application/models/Branch_model.php:38-144`, `source-refs/sanmopia-admin/application/models/Branch_model.php:288-334`, `source-refs/sanmopia-admin/application/models/Branch_model.php:345-426`, `source-refs/sanmopia-admin/application/models/Branch_model.php:591-606`	`branch_operations / BranchServiceAreaDecisionSnapshot`, `ServiceAreaPolicyVersion`	Bind first-period, second-period, extension, and continuation workflows to an effective-dated service-area decision with normalized address evidence and policy revision. Source possible/counsel/impossible rows and hard deletes must migrate as versioned profile changes and withdrawals.
P0	Caregiver candidate rank, distance, and pay authority	`source-refs/sanmopia-admin/application/models/Matching_model.php:44-124`, `source-refs/sanmopia-admin/application/models/Matching_model.php:724-862`, `source-refs/sanmopia-admin/application/models/Reservation_manager_trans_info_model.php:13-87`, `source-refs/sanmopia-manager/application/helpers/salary_helper.php:8-227`, `source-refs/sanmopia-manager/application/views/pay_info_detail.php:167-263`	`caregiver_assignment / CaregiverCandidateOrderingPolicy`, `CaregiverCandidateSnapshot`, `pricing_settlement / CaregiverCompensationQuote`, `CaregiverPayoutInstruction`	Freeze candidate limit, score components, pet exclusion, schedule proof, branch/class filters, deterministic tie seed, transport provider result/fallback, and score-vs-distance policy. Payout quotes must freeze role, custom pay, service-balance override, voucher add-ons, option labels, tax election, and tax cutover before manager/HQ screens render them.
P1	Source string, id, amount, and date compatibility	Same rows above plus `source-refs/sanmopia_web/application/views/service/step1.php:188-209`	`migration_governance / SourceCompatibilityCatalog`	Convert magic labels, relation ids, service item ids, amounts, date cutovers, branch ids, and source status strings into catalog rows, policy profiles, enum aliases, or import compatibility decisions with source evidence. None should leak into modern UI branching or domain invariants.

2026-07-05 Payment/Refund Source Pass

Gap	Legacy evidence	Modern owner	Required migration
Provider refund and paid-row transition	`source-refs/sanmopia_web/application/models/Payment_model.php:383`, `source-refs/sanmopia_web/application/models/Payment_model.php:416`, `source-refs/sanmopia_web/application/models/Payment_model.php:427`, `source-refs/sanmopia_web/application/models/Payment_model.php:429`	`pricing_settlement / PaymentRefund`, `ProviderRefundPaidRowTransition`	Refund must persist provider reversal and internal paid/refunded state in one idempotent ledger path. Source marks normal/voucher payment rows status `2` after KCP full cancel; modern ledger must not report paid after provider refund, nor mark refunded before provider success. 2026-07-06 backend foundation: `ce59da4` records provider refund result events separately from paid-row transitions, guards expected paid-row revision, settlement lock, already-refunded rows, remaining amount, partial/full refunded target state, and keeps rejected transitions as auditable events. Backend `9cc034c` adds service-role-only Supabase persistence for `ProviderRefundPaidRowTransitionDecision`, storing provider result event, source evidence, idempotency key, applied/rejected transition state, revision movement, and remaining paid amount in `sanmopia_provider_refund_paid_row_transition_decisions` with RLS and anon/authenticated revokes. Backend `e038c7c` adds `ProviderRefundReportingInvalidationPolicy`, `RecordProviderRefundReportingInvalidationsHandler`, and service-role-only Supabase persistence for `sanmopia_provider_refund_reporting_invalidations`, so provider refund results invalidate sales dashboards, branch/HQ settlement statements, settlement export artifacts, and branch/HQ operator boards with separate financial-recalculation versus operator-repair flags. Backend `8db9942` wires the invalidation policy into `ProviderRefundPaidRowTransitionHandler`, so configured provider-result recording persists both the transition decision and invalidation plan from the same provider event timestamp. Backend `fa13ef7` adds `ProviderRefundReportingProjectionRefreshRequestPlan`, queues `sanmopia_provider_refund_reporting_refresh` PGMQ messages, and marks invalidation rows `refresh_requested` with request key, queue name, and timestamp. Backend `c46382b` consumes those queue payloads through `ProviderRefundReportingProjectionRefreshHandler` and records `refreshed` or `refresh_failed` status transitions. Backend `ef0dade` adds immutable provider-refund settlement reversal-line domain/application/adapter slices, service-role-only `sanmopia_settlement_ledger_reversal_lines`, and a Tach-validated application continuation from paid-row transition request to settlement reversal command. Backend `ebf785d` exposes `/internal/provider-refund-paid-row-transitions` and wires the runtime handler to transition persistence, reporting invalidation store, PGMQ refresh requester, and settlement reversal producer. Backend `6120324` adds `/internal/provider-refund-results-from-ledger`, `ProviderRefundResultFromLedgerHandler`, and a Supabase paid-row snapshot reader so workers can send only refund intent plus provider result evidence while backend derives refund amount and current paid-row revision from ledgers. Backend `f391565` changes the Supabase decision store to call `sanmopia_record_provider_refund_paid_row_transition_decision`, which records the decision fact and advances `sanmopia_payment_records.payment_status/payment_fact_revision` under `payment_id + payment_fact_revision` guard, including full-refund `refunded` status. Backend `3e6d83f` proves workspace-domain and contract-level artifact grant revocation on repair. Backend follow-up exposes token-gated `/internal/payment-refund-repairs/provider-refund-plans` and wires `PaymentRefundRepairHandler` to Supabase persistence. Backend follow-up also exposes `/internal/payment-refund-repairs/provider-refund-executions`, calls the configured billing gateway through `PaymentGatewayClient.refund` only for new idempotency keys, persists idempotency-keyed execution attempts in `sanmopia_payment_refund_repair_execution_attempts`, replays matching stored attempts into `ProviderRefundResultFromLedgerHandler` without a second provider call, and rejects mismatched replays. Remaining runtime work: stage provider-webhook E2E, retry backoff and operator result-history projection, full sales-dashboard fact recomputation/read APIs, Supabase/stage persistence proof for grant revocation and replacement lineage, and operator-visible artifact reissue history.
Pre-reservation cancellation refund	`source-refs/sanmopia-admin/application/models/Reservation_model.php:5560`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:5567`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:5571`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:5572`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:5588`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:5591`, `source-refs/sanmopia-admin/application/libraries/Kcppayment.php:31`, `source-refs/sanmopia-admin/application/libraries/Kcppayment.php:39`, `source-refs/sanmopia-admin/application/libraries/Kcppayment.php:40`, `source-refs/sanmopia-admin/application/libraries/Kcppayment.php:42`	`pricing_settlement / PreReservationCancellationRefund`, `reservation_operations / PreReservationCancellation`, `payment_processing / ProviderRefundCommandPlan`	Admin cancellation selects only paid pre-reservation rows and calls provider refund, but source does not clearly persist payment refunded status. Stronger source gap: the status-save path passes `PAY_METHOD` and reason into a refund wrapper whose signature only accepts order id, transaction id, and `mod_desc`; the wrapper then sends full-cancel `mod_type=STSC`. Modern provider refund planning must type and persist provider method, reason, amount, idempotency key, refund capability, and provider command fields separately instead of preserving legacy argument order or treating local status write as refund authority. 2026-07-06 backend foundation: `ce59da4` now selects exactly one paid pre-reservation deposit row, records reservation cancellation status, refund request, provider requested/succeeded/failed events, and payment refund-state updates; multiple paid rows are treated as ambiguous instead of guessed. Remaining runtime work: Supabase persistence, reservation status transaction binding, provider execution/webhook binding, legacy payment-row backfill, and operator projection for failed/mismatched provider command attempts.
Partial refund support	`source-refs/sanmopia_web/application/libraries/Kcppayment.php:39`, `source-refs/sanmopia_web/application/libraries/Kcppayment.php:252`, `source-refs/sanmopia_web/application/libraries/Kcppayment.php:392`, `source-refs/sanmopia_web/application/libraries/Kcppayment.php:447`, `source-refs/sanmopia_web/application/libraries/Kcppayment.php:455`, `source-refs/sanmopia_web/application/libraries/Kcppayment.php:456`, `source-refs/sanmopia-admin/application/libraries/Kcppayment.php:31`, `source-refs/sanmopia-admin/application/libraries/Kcppayment.php:39`, `source-refs/sanmopia-admin/application/libraries/Kcppayment.php:40`	`pricing_settlement / PartialPaymentRefund`, `ProviderPartialRefundCapabilitySnapshot`, `PartialPaymentRefundProviderCommandPlan`	Source KCP payment response exposes `partcanc_yn` as provider capability evidence, but refund command still uses full cancel `mod_type=STSC`; no partial-cancel request fields were found. 2026-07-06 backend foundation: backend `90e4b00`, contract `75aaebe` now require explicit `refundAmountKrw`, remaining refundable amount, provider partial-refund support decision, and append-only provider status event before any Kill Bill command can be planned. Repair execution/result-recording persistence now proves one backend Kill Bill refund execution boundary for planned repairs. Remaining runtime work: persist provider partial-refund capability from payment closeout, bind the non-repair partial-refund execution path, reconcile provider webhooks, expose operator-facing repair/read projection, and bind settlement ledger reversal.
Payment-change closeout	`source-refs/sanmopia_web/application/views/modal/modal_change_payment.php:3-25`, `source-refs/sanmopia_web/static/js/mypage/reservation_changePayment.js:43`, `source-refs/sanmopia_web/static/js/mypage/reservation_changePayment.js:57`, `source-refs/sanmopia-user-old/src/design-system/ui-kit/islands/ChangePaymentModalIsland.tsx:41-70`, `source-refs/sanmopia-user-old/src/design-system/ui-kit/islands/ChangePaymentModalIsland.tsx:91-100`, `source-refs/sanmopia-user-old/src/data/mock/mypage/reservationChangePayment.ts:30-90`, `source-refs/sanmopia_web/application/models/Payment_model.php:856`, `source-refs/sanmopia_web/application/models/Payment_model.php:893`, `source-refs/sanmopia-admin/application/models/Payment_model.php:4507`, `source-refs/sanmopia-admin/application/models/Payment_model.php:4514`	`pricing_settlement / PaymentChangeCloseout`	UI-entered change amount creates `PAYMENT_CHANGE_TB`, unpaid old rows are deleted, provider context and `DEPOSIT_DT` are stored, and admin status `2` sets `COMPLETED_DT`. Legacy PHP and the old Astro customer modal both recompute convertible amount from coupon, pre-reservation, voucher add-on, service type, and hardcoded Korean copy; the old Astro fixture then copies `8400000`, `2100000`, and `500000` product/payment amounts into customer-visible scenarios. Modern backend owns amount validation, catalog-issued payment-change fixture templates, deposited/completed timestamps, customer-facing amount breakdown/copy, admin closeout, and audit trail. 2026-07-06 backend follow-up: payment-change pre-registration and paid verification now reject provider-returned amount drift against the frozen mother-payable adjustment before saving pre-registration, payment receipt, or settlement continuation.
Coupon restore and product coupon regeneration	`source-refs/sanmopia_web/application/models/Coupon_model.php:529`, `source-refs/sanmopia_web/application/models/Coupon_model.php:541`, `source-refs/sanmopia-admin/application/models/Coupon_model.php:936`, `source-refs/sanmopia-admin/application/models/Coupon_model.php:947`, `source-refs/sanmopia-admin/application/models/Coupon_model.php:63`, `source-refs/sanmopia-admin/application/models/Coupon_model.php:151`	`promotion / CouponRestoration`, `pricing_settlement / RefundSideEffectPlan`	Source restores used coupons by resetting `USE_FL/USE_DT` and logs reuse; admin cancel/stop deletes/recreates product coupon from attendance days. Modern flow needs actor/reason event, entitlement restore, product coupon reset by frozen service-day policy, and repairable outbox.
Settlement continuation after branch deposit	`source-refs/sanmopia-admin/application/controllers/Calculate.php:219`, `source-refs/sanmopia-admin/application/controllers/Calculate.php:248`, `source-refs/sanmopia-admin/application/controllers/Calculate.php:291`, `source-refs/sanmopia-admin/application/models/Payment_model.php:2977`, `source-refs/sanmopia-admin/application/models/Payment_model.php:3003`, `source-refs/sanmopia-admin/application/models/Payment_model.php:4265`, `source-refs/sanmopia-admin/application/models/Payment_model.php:4386`	`pricing_settlement / SettlementContinuation`	Source board status `1/3` can become settled `2` or arrears `4`; detail/coupon/fee flags mark paid pieces; data-room close sets board `STATUS_FL=1` and coupon `PAYMENT_STATUS_FL=2`. Modern continuation needs board state machine, component-level paid facts, idempotency, and closeout command.

2026-07-05 Legacy Feature Curator Pass

These rows add under-described PHP-side behavior found in reservation/payment, pricing, settlement, caregiver wage, and matching sources. Source names stay adapter evidence only.

Checklist item	Source evidence	Modern target bounded context	Modern abstraction note
Voucher support subsidy and customer charge display	`source-refs/sanmopia_web/application/models/Reservation_model.php:1261-1288`, `source-refs/sanmopia_web/application/models/Reservation_model.php:1295-1310`, `source-refs/sanmopia_web/application/models/Reservation_model.php:1318-1331`, `source-refs/sanmopia_web/application/models/Reservation_model.php:1354-1369`, `source-refs/sanmopia_web/application/controllers/api/Service.php:749-755`, `source-refs/sanmopia_web/application/models/Reservation_model.php:3131-3136`, `source-refs/sanmopia-admin/application/views/reservation_status/reservation_price_table.php:26-35`, `source-refs/sanmopia-admin/application/views/reservation_status/reservation_price_table.php:84-99`, `source-refs/sanmopia-admin/application/views/reservation_status/reservation_price_table.php:191-199`, `source-refs/sanmopia-admin/application/views/reservation_status/reservation_price_table.php:235-240`, `source-refs/sanmopia_web/application/views/mypage/item/reservation_fee_table.php:12-15`, `source-refs/sanmopia_web/application/views/mypage/item/reservation_fee_table.php:81-89`, `source-refs/sanmopia_web/application/views/mypage/item/reservation_fee_table.php:177-180`, `source-refs/sanmopia_web/application/views/mypage/item/reservation_fee_table.php:327-332`	`pricing_settlement / VoucherSupportSubsidyChargeSnapshot`, `pricing_settlement / VoucherServiceBalanceCustomPriceSnapshot`, `reservation_operations / ReservationChargeFinalization`, `ReservationPaymentSchedule`	Backend foundation now adds `VoucherSupportSubsidyChargeSnapshotPolicy`, which reuses `ReservationPriceSummaryPolicy` and freezes service catalog price, public support subsidy, regional support discount, customer-share before credit, coupon/pre-reservation credits, voucher add-ons, deposit/balance split, service balance, customer total due, display label keys, and source evidence. Hidden source side effect: reservation apply recomputes live voucher `leftPrice` for in-home/special service and writes `SERVICE_BALANCE_PRICE` plus `SERVICE_BALANCE_PRICE_USE_FL=1` back to the reservation. Remaining work: persist snapshot rows, expose generated contract/read model, bind reservation payment schedule, and make voucher service-balance custom price a backend-issued charge-finalization fact with expected reservation/price revision and reporting/settlement invalidation.
Product gift coupon timing and cancellation downgrade	`source-refs/sanmopia-admin/application/config/constants.php:276-277`, `source-refs/sanmopia-admin/application/models/Coupon_model.php:72-76`, `source-refs/sanmopia-admin/application/models/Coupon_model.php:100-103`, `source-refs/sanmopia-admin/application/models/Coupon_model.php:122-136`, `source-refs/sanmopia-admin/application/models/Coupon_model.php:225-228`, `source-refs/sanmopia-admin/application/models/Coupon_model.php:265-284`, `source-refs/sanmopia-admin/application/models/Coupon_model.php:307-319`, `source-refs/sanmopia-admin/application/models/Payment_model.php:1225-1250`, `source-refs/sanmopia-admin/application/models/Payment_model.php:1573-1585`, `source-refs/sanmopia-admin/application/models/Payment_model.php:3883-3887`	`promotion_entitlement / ProductGiftCouponEligibility`, `pricing_settlement / CancelledGiftCouponCommissionPolicy`	Attendance-based actual service days choose no coupon/1-week/2-week grant, publish date uses 3-day or 8-day offset by service term and working type, and settlement uses 20,000/30,000 coupon value plus 5,000/10,000 cancelled-coupon fee. Replace with versioned entitlement and commission policies.
Caregiver wage helper and tax election	`source-refs/sanmopia-manager/application/helpers/salary_helper.php:42-64`, `source-refs/sanmopia-manager/application/helpers/salary_helper.php:78-99`, `source-refs/sanmopia-manager/application/helpers/salary_helper.php:151-198`, `source-refs/sanmopia-manager/application/helpers/salary_helper.php:206-226`, `source-refs/sanmopia-manager/application/views/pay_info_detail.php:100-103`, `source-refs/sanmopia-manager/application/views/pay_info_detail.php:182-190`, `source-refs/sanmopia-manager/application/views/pay_info_detail.php:234-240`, `source-refs/sanmopia-admin/application/controllers/Manager.php:1142-1165`, `source-refs/sanmopia-admin/application/controllers/Manager.php:1917-1959`	`pricing_settlement / CaregiverCompensationQuote`, `CaregiverPayoutInstruction`, `CaregiverTaxElection`	Main/sub role, sort, custom salary, service-balance override, voucher pure additional price, in-home/special add pay, 4대보험 vs 3.3% tax election, and 2022-03-29 cutoff must be immutable payout quote inputs. Manager/caregiver portals render backend quote only.
Branch settlement remittance account and fee catalog	`source-refs/sanmopia-admin/application/config/constants.php:286-287`, `source-refs/sanmopia-admin/application/views/calculate_detail.php:190-193`, `source-refs/sanmopia-admin/application/views/calculate_detail.php:256-283`, `source-refs/sanmopia-admin/application/views/calculate_detail.php:360-386`, `source-refs/sanmopia-admin/application/views/calculate_detail.php:941-954`, `source-refs/sanmopia-admin/application/models/Payment_model.php:1526`, `source-refs/sanmopia-admin/application/models/Payment_model.php:1550`, `source-refs/sanmopia-admin/application/models/Payment_model.php:2081-2088`, `source-refs/sanmopia-admin/application/controllers/Common.php:106`	`pricing_settlement / SettlementRemittanceAccountSnapshot`, `SettlementPricingPolicy`	Hardcoded HQ account text, normal/voucher account columns, voucher fee `15,000`, manual gift-fee count/price fields, membership, delivery, and cancelled coupon fees must be effective-dated settlement policy snapshots with branch/HQ/Danbee scope.
Voucher price import and support catalog validation	`source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:5028-5053`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:5078-5108`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:5158-5183`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:5247-5252`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:5353-5360`, `source-refs/sanmopia_web/application/controllers/api/Service.php:913-914`	`pricing_settlement / VoucherPriceCatalogImport`, `SupportSubsidyRuleCatalog`, `service_calendar / ServiceCalendarOptionPriceCatalog`	Spreadsheet import validates service price, government support, own price, before/after-tax caregiver pay, in-home conversion, Saturday/holiday options, and consume-type version. Modern import needs dry-run diff, validation artifact, policy version, and rollback audit before booking/payment use.
Customer smart matching preview and pick override	`source-refs/sanmopia_web/application/controllers/Service.php:603-622`, `source-refs/sanmopia_web/application/controllers/api/Service.php:592-624`, `source-refs/sanmopia_web/application/controllers/api/Service.php:787-810`, `source-refs/sanmopia_web/application/models/Manager_matching_model.php:16`, `source-refs/sanmopia_web/application/models/Manager_matching_model.php:73-74`, `source-refs/sanmopia_web/application/models/Smart_matching_model.php:219-235`, `source-refs/sanmopia_web/application/models/Smart_matching_model.php:248-252`	`caregiver_assignment / CustomerSmartMatchingPreferenceSnapshot`, `CandidatePreviewPolicy`, `CaregiverPickOverrideCommand`	Customer PHP flow writes pet/religion/preference/personality facts, previews top 5 candidates with class and branch filters, then direct pick deletes matching facts and sets `PICK_MANAGER_FL`. Modern flow needs append-only preference revision, deterministic preview reason, override command, and no silent preference deletion.

2026-07-05 Static JS/Admin View Curator Pass

These rows add hidden browser/admin/mobile-adjacent behavior found after the PHP pass. Source ids and app schemes are adapter evidence only.

Checklist item	Source evidence	Modern target bounded context	Modern abstraction note
Admin reservation status command surface	`source-refs/sanmopia-admin/application/config/constants.php:120-160`, `source-refs/sanmopia-admin/application/views/reservation_status/reservation_detail.php:82-147`, `source-refs/sanmopia-admin/application/views/reservation_status/reservation_detail.php:244-256`, `source-refs/sanmopia-admin/static/js/reservation_status/reservation_detail.js:271-320`, `source-refs/sanmopia-admin/application/views/reservation_status/pre_reservation_detail.php:90-118`, `source-refs/sanmopia-admin/static/js/reservation_status/pre_reservation_detail.js:299-328`	`reservation_operations / ReservationLifecycleCommandSurface`, `SourceReservationStatusTransitionCatalog`, `ReservationWorkspaceConflictGuard`	Admin views build allowed status options from raw ids, skip `18` in one selector, post `freservation-status` inside broad detail forms, and gate matching UI by `15/16/9`. Backend must expose command availability, expected revision, disabled reason, and side-effect plan.
Admin overwrite flows for branch, memo, and price version	`source-refs/sanmopia-admin/application/views/reservation_status/reservation_detail.php:216-231`, `source-refs/sanmopia-admin/application/views/reservation_status/reservation_detail.php:1463-1478`, `source-refs/sanmopia-admin/application/controllers/ajax/Reservation.php:22-28`, `source-refs/sanmopia-admin/application/models/Branch_model.php:23-46`, `source-refs/sanmopia-admin/static/js/reservation_status/reservation_detail.js:1029-1056`, `source-refs/sanmopia-admin/application/controllers/Reservation.php:1823-1846`, `source-refs/sanmopia-admin/static/js/reservation_status/reservation_detail.js:1078-1086`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:5252-5256`	`reservation_operations / ReservationBranchHandoffCommand`, `ReservationPriceVersionRequoteCommand`, `ReservationMemoRevision`; `pricing_settlement / RequoteImpactPlan`	Branch handoff posts only reservation/branch ids, price version JS hardcodes version labels, and memo onchange writes directly. Replace with typed commands carrying actor, reason, expected revision, before/after diff, pricing/assignment/settlement impact, and conflict UX.
Admin care-team matching overlay and slot rules	`source-refs/sanmopia-admin/application/views/reservation_status/reservation_detail.php:44-53`, `source-refs/sanmopia-admin/application/views/reservation_status/reservation_detail.php:842-958`, `source-refs/sanmopia-admin/static/js/reservation_status/reservation_detail.js:554-564`, `source-refs/sanmopia-admin/static/js/reservation_status/reservation_detail.js:591-618`, `source-refs/sanmopia-admin/static/js/reservation_status/reservation_detail.js:680-728`, `source-refs/sanmopia-admin/application/controllers/ajax/Reservation.php:32-42`, `source-refs/sanmopia-admin/application/controllers/ajax/Reservation.php:181-201`	`caregiver_assignment / CareTeamSlotPolicy`, `AssignmentCandidateScoreProjection`, `AssignmentOverrideCommand`, `AssignmentChangeHistoryReadModel`	Admin modal owns main/sub slot labels, multi-caregiver count rules, duplicate caregiver rejection, score display, religion/preference match highlights, distance/transit text, and change-history rendering. Backend must return slot policy, candidate reasons, override eligibility, and immutable assignment history.
Native payment/deep-link bridge catalog	`source-refs/sanmopia_android/app/src/main/java/com/sanmopia/app/networks/PaymentScheme.java:7-25`, `source-refs/sanmopia_android/app/src/main/java/com/sanmopia/app/web/SanmopiaClient.java:33-70`, `source-refs/sanmopia_android/app/src/main/java/com/sanmopia/app/web/SanmopiaClient.java:73-103`, `source-refs/sanmopia_ios/ios_sanmopia_app/Info.plist:54-91`, `source-refs/sanmopia_ios/ios_sanmopia_app/ViewController.swift:43-47`, `source-refs/sanmopia_ios/ios_sanmopia_app/ViewController.swift:105-108`, `source-refs/sanmopia_ios/ios_sanmopia_app/ViewController.swift:197-202`, `source-refs/sanmopia_manager_android/app/src/main/java/com/sanmopia/manager/MainActivity.java:301-307`	`customer_engagement / MobileAppEntryPoint`; `pricing_settlement / PaymentRedirectCapability`; `platform / NativeShellBridgePolicy`	Native shells whitelist/payment-route app schemes, open market fallbacks, generic non-http URLs, web dialogs, push URLs, and tel links. Modern contracts need versioned bridge capabilities and allowlisted destinations; payment amount/purpose stays backend-frozen before any native redirect.

2026-07-05 Coupon/Settlement Detail Addendum

These rows narrow earlier broad coupon and settlement rows with source-specific recognition timing and fee authority.

Checklist item	Source evidence	Modern target bounded context	Modern abstraction note
Product gift coupon settlement recognition timing	`source-refs/sanmopia-admin/application/models/Coupon_model.php:263-320`, `source-refs/sanmopia-admin/application/models/Payment_model.php:896-916`, `source-refs/sanmopia-admin/application/models/Payment_model.php:918-933`, `source-refs/sanmopia-admin/application/models/Payment_model.php:1554-1592`, `source-refs/sanmopia-admin/application/views/calculate_detail.php:1091-1109`, `source-refs/sanmopia-admin/static/js/calculate_detail.js:1053-1080`	`promotion_entitlement / ProductCouponEntitlementSchedule`; `pricing_settlement / PromotionalCouponCostRecognition`, `CancelledGiftCouponCommissionPolicy`	Source creates product coupons with 3-day/8-day publish dates, but branch settlement recognizes live coupon cost by user grant month and deleted coupon commission by `SERVICE_START_DT + 15 days`; admin UI can still select rows and add manual cancelled-coupon totals. Freeze entitlement schedule, recognition period, line kind, rate band, paid-state revision, and manual override audit in backend.
Branch settlement fee catalog and client-total authority	`source-refs/sanmopia-admin/application/models/Payment_model.php:838-845`, `source-refs/sanmopia-admin/application/models/Payment_model.php:872-893`, `source-refs/sanmopia-admin/application/models/Payment_model.php:941-945`, `source-refs/sanmopia-admin/application/models/Payment_model.php:1180-1208`, `source-refs/sanmopia-admin/application/models/Payment_model.php:1223-1250`, `source-refs/sanmopia-admin/application/views/calculate_detail.php:1183-1198`, `source-refs/sanmopia-admin/application/views/calculate_detail.php:1407-1424`, `source-refs/sanmopia-admin/static/js/calculate_detail.js:939-1047`, `source-refs/sanmopia-admin/static/js/calculate_detail.js:1053-1144`	`pricing_settlement / SettlementPricingPolicy`, `BranchSettlementFeeCatalog`, `SettlementStatementLineProjection`, `SettlementCompletionReview`	Source mixes monthly branch membership overrides, voucher `15,000` fee, editable delivery price, coupon/cancelled-coupon flags, manual etc rows, and JS recomputed result totals. UI must submit line acknowledgements or manual adjustment commands with expected revisions; backend owns catalog rates, eligibility, totals, paid flags, and arrears/settled review.

2026-07-05 Data-Room/Document Export Addendum

These rows add export/render-specific gaps found in settlement data room and daily-report document generation paths.

Checklist item	Source evidence	Modern target bounded context	Modern abstraction note
Settlement workbook render-time formula authority	`source-refs/sanmopia-admin/application/controllers/Calculate.php:569-577`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3741-3750`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3792-3808`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3864-3880`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3893-3910`, `source-refs/sanmopia-admin/static/js/calculate_detail.js:331-336`	`pricing_settlement / SettlementExportDatasetSnapshot`; `document_reporting / SettlementExportWorksheetPolicy`, `SettlementArtifactVersion`	Source builds `type18` settlement workbooks directly from current board/payment rows, inserts rows after template line 23, recalculates coupon payment-method fees in the renderer, and writes `SUM` formulas before streaming `php://output`. Export worker must consume frozen settlement lines, formula policy version, dataset revision, artifact checksum, and signed download grant; renderer must not create financial authority.
Document template slots, static PDFs, and converter boundary	`source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:15-39`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3914-4198`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4284-4430`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4434-4598`, `source-refs/sanmopia_web/application/controllers/api/ReservationDocument.php:21-54`, `source-refs/sanmopia_web/application/views/mypage/reservation_document.php:45-123`	`document_reporting / PrintableTemplateRegistry`, `DocumentRenderProviderAdapter`, `StaticPdfTemplateArtifact`, `DocumentRenderAttempt`, `DocumentAccessGrant`	Source mixes numeric XLSX slots, static PDF files, temp ZIP files, external XLSX-to-PDF conversion, base64/binary response shapes, token query URLs, and direct browser/app download handoff. Modern registry must version template kind/render format, isolate converter credentials in provider config, persist render attempts/artifacts, and expose only scoped signed grants.
Daily report finality parity across save, export, and reward	`source-refs/sanmopia_web/application/models/Report_model.php:340-381`, `source-refs/sanmopia_web/application/models/Report_model.php:467-509`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4030-4050`, `source-refs/sanmopia_web/application/controllers/api/Report.php:79-109`, `source-refs/sanmopia_web/application/models/Report_model.php:553-615`	`care_delivery / DailyCareReportServiceDatePolicy`; `customer_daily_report_review / ReportFinalityDecision`, `CustomerDailyReportReviewRewardGrant`; `document_reporting / DailyReportArtifactSeriesSelection`	Source marks stop day as final in report lists/export templates, but customer save/rating branches only on service end date, while reward grant counts eligible report dates. One backend finality/readiness decision must drive report save, main/assistant rating requirement, stop/resume windows, artifact series, and once-per-reservation reward grant.

2026-07-05 CaveCrew Explorer A Hidden Feature Delta

These rows focus on smaller legacy behaviors not fully captured by broader pricing, refund, settlement, matching, family, document, and reporting rows.

Checklist item	Source evidence	Modern target bounded context	Modern abstraction note
Branch request notification routing and special secondary recipient	`source-refs/sanmopia_web/application/controllers/api/Reservation.php:141-190`, `source-refs/sanmopia_web/application/controllers/api/Reservation.php:192-228`	`reservation_operations / ReservationCustomerChangeRequestWorkflow`; `communication_delivery / BranchActionNotificationRoutingPolicy`	Customer cancel, stop, and change requests are not only status changes: source sends branch AlimTalk, distinguishes instant cancel from cancel request, and special-cases branch `20` with a second phone number. Modern workflow must freeze request kind, instant-vs-approval path, branch routing recipients, notification template, actor, and idempotency before reservation/refund side effects run.
Pre-reservation cancellation refund tied to status write	`source-refs/sanmopia-admin/application/models/Reservation_model.php:5560-5577`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:5580-5595`	`pricing_settlement / PreReservationCancellationRefundIntent`; `reservation_operations / PreReservationStatusTransitionCommand`	Admin status save to legacy status `9` triggers KCP refund lookup for paid voucher pre-reservation payment type `6` by extracting `ordr_idxx`, `tno`, and pay method from JSON. Modern transition must create an explicit refund intent, provider context snapshot, ledger reversal, and status-transition result instead of hiding refund inside a generic status update.
Data-room inbox/outbox board with branch-scoped file grants	`source-refs/sanmopia-admin/application/controllers/DataRoom.php:97-197`, `source-refs/sanmopia-admin/application/models/Data_room_model.php:22-80`, `source-refs/sanmopia-admin/application/models/Data_room_model.php:82-184`, `source-refs/sanmopia-admin/application/views/table/data_room/table_other_post_list.php:1-114`	`document_reporting / BranchDocumentMailbox`; `document_reporting / DocumentAttachmentGrant`; `operator_access / BranchDocumentMailboxPermission`	Legacy “other data room” is a send/receive mailbox, not plain CMS content. HQ/branch visibility depends on write branch, receive branch, `36` headquarters fallback, board type, fixed posts, and edit/delete capability. Modern model needs mailbox direction, participant branch snapshots, attachment grants, immutable file versioning, and actor-scoped edit/delete decisions.
All-document bundle composition by service type	`source-refs/sanmopia-admin/application/controllers/DataRoom.php:311-386`, `source-refs/sanmopia-admin/application/views/data_room/form_reservation_list.php:130-208`, `source-refs/sanmopia-admin/application/controllers/ajax/DataRoom.php:66-129`	`document_reporting / ReservationDocumentBundlePolicy`; `document_reporting / ReservationDocumentSelectionToken`	Legacy form id `16` composes different document id arrays for voucher vs normal service and posts selected reservation ids through a hidden iframe. Modern export must move service-type bundle rules, single-vs-multi select constraints, reservation eligibility, and selection token validation into backend before artifact rendering.
Caregiver one-line review visibility moderation	`source-refs/sanmopia-admin/application/models/Manager_model.php:2194-2217`, `source-refs/sanmopia-admin/application/models/Manager_model.php:2219-2240`, `source-refs/sanmopia-manager/application/views/manager_info.php:433-435`	`care_delivery / CaregiverReviewVisibilityDecision`; `customer_engagement / PublicCaregiverReviewProjection`	Source lets admin hide/show customer one-line comments separately for main and sub caregivers, while manager profile renders only `SHOW_FL = 1`. Modern review projection needs moderation command, actor/reason/audit, primary/sub caregiver scope, and public-read projection; daily report rating and public profile display must not read raw flags directly.
Caregiver-to-HQ request and reply workflow	`source-refs/sanmopia-manager/application/controllers/User.php:373-425`, `source-refs/sanmopia-manager/application/models/Request_model.php:11-52`, `source-refs/sanmopia-admin/application/models/Office_management_model.php:259-284`, `source-refs/sanmopia-admin/application/models/Faq_model.php:86-100`	`caregiver_engagement / CaregiverHeadquartersRequestThread`; `communication_delivery / HeadquartersRequestNotificationPolicy`	Manager app writes “message to HQ” rows, pushes a hardcoded phone notification, lets caregiver edit/delete own requests, and admin later stores `ANSWER` plus `ANSWER_DATE`. Modern flow needs request thread, reply state, assignee/actor audit, notification recipient policy, retention rules, and no hardcoded phone dependency.

Legacy UI/PHP Calculation Migration Rule

Legacy UI/PHP calculations are source evidence only. They must migrate to backend domain policy, application commands, or backend-owned read models before frontend work is considered complete.

Money, tax, payroll, subsidy, coupon, fee, refund, and settlement arithmetic belongs in pricing_settlement, reservation_operations, or the owning application command/read-model layer.
Status buttons, detail tabs, document readiness, report obligations, payment actions, and actor-visible fields belong in backend projections with disabled reasons, command targets, revision, and policy/catalog version.
Frontend portals may render Nanostores state from generated clients and submit explicit commands. They must not recompute totals, map source status ids, infer workflow state, choose payment routes, build document URLs, or decide SpiceDB/OPA capability outcomes.
Source terms, table names, numeric ids, and UI flags stay in adapters, source-evidence docs, or versioned compatibility catalogs. They must not name target aggregates, command payloads, or frontend state contracts.

CaveCrew Source Gap Queue

This queue comes from the 2026-07-05 legacy source pass. Source behavior here is evidence only: modern work must improve the model, move UI/PHP calculations into backend commands/projections, and keep source-era names behind adapters or source evidence.

Latest focused source-status/payment mapping lives in Status Payment Settlement Source Map. Use it to refine existing rows instead of adding duplicate checklist entries for settlement statuses, payment/refund ids, document ids, and caregiver payout or matching source terms.

Current Closeout Flow Marker

Actor labels in gap docs map to target role contracts: Branch Operator means BranchOwner, HQ Admin means HeadOfficeManager, Mother means Mother/FamilySponsor, and Caregiver means CareManager. The current backend closeout target is one backend-owned path:

flowchart LR
  Booking[Booking] --> Payment[Payment closeout]
  Payment --> Balance[Service-balance closeout]
  Balance --> Receipt[Caregiver receipt]
  Receipt --> Settlement[Branch/HQ settlement continuation]
  Branch[Branch Operator] --> Balance
  Caregiver[Caregiver] --> Receipt
  HQ[HQ Admin] --> Settlement
  Mother[Mother] --> Booking

Persistence rule: Supabase remains the durable ledger/read/RLS layer. Service role adapters may write closeout ledgers and workflow rows; actor portals read RLS-scoped projections with caller JWTs. Use RPC for multi-table booking or closeout commits when partial Data API writes would expose mismatched payment, service-balance, receipt, or settlement state.

Remaining unchecked legacy PHP closeout gaps:

Service-balance PHP flags and zero-balance auto-complete must be expressed as backend ServiceBalancePaymentCloseout decisions, not copied column names.
Primary/sub caregiver receipt flags must map to assignment-key recipients, caregiver role, and handoff order.
Branch/HQ settlement continuation must consume closeout facts from the same Supabase financial lifecycle rows used by payment closeout.
Operator repair/audit screens must cover closeout conflict, retry, and receipt correction before legacy PHP board parity is closed.

CaveCrew Reconciliation Delta 2026-07-05

This pass reconciles new legacy evidence with existing queue rows instead of adding duplicate backlog items. Treat these as strengthening requirements for the named modern slices.

Legacy evidence	Existing modern target	Reconciliation requirement
`source-refs/sanmopia-admin/application/config/constants.php:291`, `source-refs/sanmopia_web/application/controllers/api/Service.php:296`	`pricing_settlement / PriceCatalogVersionResolution`, `ReservationPriceVersionSnapshot`	Freeze the resolved normal/voucher catalog version on extension and continuation flows before payment, refund, or settlement handoff.
`source-refs/sanmopia-admin/application/models/Reservation_model.php:647`	`pricing_settlement / AdditionalServiceChargePolicy`	Replace source string branches for Saturday, holiday, and regional add-ons with typed charge components and parity tests.
`source-refs/sanmopia-admin/application/models/Reservation_model.php:4153`, `source-refs/sanmopia_web/application/controllers/api/Service.php:367`	`service_calendar / ServicePeriodCalendarPolicy`, `RegionalBenefitServiceDayBonus`	Service term, weekend/holiday selection, substitute holiday, and regional service-day bonus must be one backend calendar decision that invalidates quote, matching, report, refund, and settlement projections.
`source-refs/sanmopia-admin/application/models/Reservation_model.php:5985`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:6131`, `source-refs/sanmopia_web/application/controllers/api/Service.php:749`	`pricing_settlement / VoucherServiceAddOnPolicy`, `VoucherPureAdditionalServiceBalance`	Voucher in-home/special conversion and custom service-balance deltas must be typed backend decisions; Korean label maps remain source-adapter evidence only.
`source-refs/sanmopia_web/application/models/Payment_model.php:383`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:5581`, `source-refs/sanmopia_web/application/models/Payment_model.php:856`	`pricing_settlement / ReservationRefundCloseout`, `PreReservationRefundPolicy`, `PaymentChangeAdjustment`	Refund, pre-reservation refund, payment-change, provider context, ledger reversal, and receipt artifacts must close through the Kill Bill-backed ledger path with focused KCP parity tests.
`source-refs/sanmopia-admin/application/models/Payment_model.php:96`, `source-refs/sanmopia-admin/application/models/Payment_model.php:828`, `source-refs/sanmopia-admin/application/models/Payment_model.php:4382`	`pricing_settlement / ExternalCounterpartySettlementWorkflow`, `BranchSettlementWorkflow`, `HeadOfficeSettlementLedger`	Keep Danbee, branch, HQ, and inter-office settlement as separate workflows with explicit completion gates, statement revisions, and actor-scoped audit.
`source-refs/sanmopia-admin/application/models/Payment_model.php:3909`	`pricing_settlement / PaymentMethodFeePolicy`	Compare legacy payment-version fee rates with modern payment-method fee snapshots; fees are catalog facts, not UI/view calculations.
`source-refs/sanmopia-admin/application/models/Matching_model.php:44`, `source-refs/sanmopia-admin/application/models/Matching_model.php:760`	`caregiver_assignment / CaregiverMatchScore`, `CaregiverTravelTimeEstimate`	Matching score must freeze preference, availability, pet exclusion, grade, branch scope, and travel-time freshness instead of recomputing opaque source ordering.
`source-refs/sanmopia-admin/application/models/Reservation_manager_salary_model.php:21`, `source-refs/sanmopia-admin/application/models/Reservation_manager_salary_model.php:112`	`pricing_settlement / CaregiverPayoutInstruction`, `CaregiverTaxElection`	Main/sub caregiver payout rows need role slot, tax election, memo, grade, assignment term, attendance, and confirmation evidence as immutable payout instructions.
`source-refs/sanmopia_web/application/views/mypage/reservation_detail.php:75-138`, `source-refs/sanmopia_web/application/views/mypage/reservation_detail.php:421-451`, `source-refs/sanmopia_web/application/views/mypage/reservation_detail.php:458-466`, `source-refs/sanmopia_web/application/views/mypage/item/reservation_fee_table.php:8-21`, `source-refs/sanmopia_web/application/views/mypage/item/reservation_fee_table.php:80-95`, `source-refs/sanmopia_web/application/views/mypage/item/reservation_fee_table.php:111-180`, `source-refs/sanmopia_web/application/views/mypage/item/reservation_fee_table.php:186-205`, `source-refs/sanmopia_web/application/controllers/api/Payment.php:89-113`, `source-refs/sanmopia_web/application/controllers/api/Payment.php:353-382`, and `source-refs/sanmopia_web/application/controllers/MyReservation.php:149-158`	`pricing_settlement / MotherVisibleChargeSummary`, `pricing_settlement / ReservationPaymentActionAvailability`, `pricing_settlement / CustomerPaymentInstructionProjection`, `pricing_settlement / VirtualAccountInstructionDisplayGrant`	Mother-facing money totals, coupons, pre-reservation offsets, voucher add-on subtraction, payment button visibility, virtual-account display, and deposit/balance submit gates must be backend projections. Legacy views/controllers infer allowed payment actions from mutable `PAYMENT_INFO` Korean status strings, reservation status ids, service end date, local `PRICE_TABLE` fallback totals, and provider JSON. Modern backend must issue purpose-specific action/read-model rows with amount source, allowed methods, disabled reason, provider instruction reference, expected payment revision, and refresh/revoke facts after refund, closeout repair, virtual-account lifecycle movement, or service-balance instruction changes. Frontend remains display-only.
`source-refs/sanmopia_web/application/controllers/api/Service.php:411`	`reservation_operations / ServicePeriodPlan`, `ServiceDayOccurrence`	Voucher step3 must ignore forged browser `endDate`; backend recomputes from start date, regional service-day bonus, selected Saturday/holiday rows, and freezes occurrence snapshots.
`source-refs/sanmopia_web/application/models/Payment_model.php:233`	`pricing_settlement / CouponPrepaymentQuote`, `promotion_entitlement / PromotionEntitlement`	Coupon plus pre-reservation credit needs parity tests for own price greater/equal/less than prepayment, emits one entitlement fact, and prevents double discount.
`source-refs/sanmopia_web/static/js/mypage/reservation_changePayment.js:43`, `source-refs/sanmopia_web/application/models/Payment_model.php:856`	`pricing_settlement / PaymentAdjustmentQuote`, `PaymentChangeAdjustment`	Payment-change maximum must derive from frozen charge snapshot; reject UI amount above eligible, and superseded unpaid rows need explicit cancel event instead of silent delete.
`source-refs/sanmopia_web/application/models/Reservation_model.php:1277`, `source-refs/sanmopia_web/application/models/Reservation_model.php:3177`	`pricing_settlement / VoucherInhomeAddOnQuote`	Voucher in-home/special add-on must quote by price version, detail, baby type, delivery count, consume-type version, and service days without runtime date/label branching.
`source-refs/sanmopia-admin/application/models/Payment_model.php:4155`	`pricing_settlement / ServiceBalanceOverrideDecision`, `VoucherPureAdditionalServiceBalance`	Service-balance quote equals manager before-tax pay plus selected Saturday/holiday add-day charges plus non-extra add-ons times canonical service-day count; voucher pure-additional closeout subtracts the backend voucher add-on decision from the posted service-balance amount.
`source-refs/sanmopia_web/application/controllers/api/Payment.php:456`	`pricing_settlement / PaymentProviderTemplatePayload`, `PaymentProductCommunicationRoute`	Pre-reservation virtual-account notice must render frozen `realPrePrice`, never hardcoded `100000`; zero amount closes out without provider wait.
`source-refs/sanmopia_web/application/models/Payment_model.php:383`	`pricing_settlement / PaymentCloseout`, `RefundQuote`, `PaymentRefundIntent`	No gateway context or zero paid rows still persist zero-gateway refund quote and ledger fact before coupon, benefit, or settlement unlock.
`source-refs/sanmopia-admin/application/controllers/Calculate.php:248-309`, `source-refs/sanmopia-admin/application/models/Payment_model.php:2977-3011`, `source-refs/sanmopia-admin/application/models/Payment_model.php:3033-3051`, `source-refs/sanmopia-admin/application/models/Payment_model.php:4302-4308`, `source-refs/sanmopia-admin/application/models/Payment_model.php:4382-4419`	`pricing_settlement / SettlementCompletionReview`, `SettlementLineAcknowledgement`, `SettlementComponentAcknowledgementRevision`	Board status must derive from membership, delivery, cancelled coupon, detail rows, coupon rows, and manual adjustment acknowledgements into request `1`, complete `2`, arrears/re-request `3`, idempotently and with expected statement/component revisions. Branch/HQ UI may acknowledge projected components only; mutable `STATUS_FL`, checkbox state, and reservation-id-only detail ids are legacy evidence.
`source-refs/sanmopia-admin/application/models/Payment_model.php:3748`	`pricing_settlement / PaymentProductPlan`, `LegacyPaymentVersionCompatibility`	Voucher payment split: version `0` and adjusted own price over `100000` creates 10% deposit/90% balance, `<=100000` deposits all, version `1` creates single obligation after benefit.
`source-refs/sanmopia-admin/static/js/calculate_detail.js:769-818`, `source-refs/sanmopia-admin/static/js/calculate_detail.js:930-1079`, `source-refs/sanmopia-admin/application/controllers/Calculate.php:155-190`, `source-refs/sanmopia-admin/application/controllers/Calculate.php:219-240`, `source-refs/sanmopia-admin/application/models/Payment_model.php:534-573`, `source-refs/sanmopia-admin/application/models/Payment_model.php:658-723`, `source-refs/sanmopia-admin/application/models/Payment_model.php:2861-2878`	`pricing_settlement / SettlementArithmeticDecision`, `SettlementManualAdjustmentLine`, `SettlementClientTotalComparison`	Browser settlement totals, voucher `15,000` count math, delivery price, cancelled-coupon fee, monthly fee, and manual etc rows become comparison evidence only. Canonical backend must recompute statement totals from settlement ledger/component projections and reject mismatched total, fee, result, delivery, coupon-fee, or manual-adjustment payloads before mutating payment flags, coupon flags, board id, or branch/HQ request state.

Source evidence	Modern target	Status	Required backend replacement
`source-refs/sanmopia-admin/application/controllers/Reservation.php`, `source-refs/sanmopia-admin/static/js/reservation_status/reservation_detail.js`	`reservation_operations / reservation_collaboration`	Partial	`ReservationOperationWorkspace` with narrow commands, expected revision, conflict log, return-state token, and no `history.back()` last-write-wins save.
`source-refs/sanmopia_web/application/controllers/api/Reservation.php`, `source-refs/sanmopia_web/application/models/Report_model.php`	`reservation_operations / service_suspension`	Partial	Durable `ServiceSuspensionInterval` plus quote, assignment, coupon, report, and notification impact outbox.
`source-refs/sanmopia_web/static/js/step3.js`, `source-refs/sanmopia_web/application/models/Reservation_model.php`	`reservation_operations / service_period`, `reservation_operations / service_calendar`	Partial	Immutable `ServicePeriodPlanningRequest`, `ServicePeriodPlan`, and `ServiceDayOccurrence` snapshots for weekly, extension, weekend, holiday, substitute holiday, and branch holiday rules. Domain owns service-period policy language; application contracts own incoming command payloads and legacy compatibility fields.
`source-refs/sanmopia-admin/application/models/Branch_model.php`, `source-refs/sanmopia_web/application/controllers/api/Service.php`	`branch_operations / service_area_policy`	Partial	Booking-bound `ServiceAreaDecisionSnapshot` with address levels, serviceability, consultation-only, impossible-region, and policy evidence.
`source-refs/sanmopia_web/application/controllers/api/Payment.php`, `source-refs/sanmopia_web/application/models/Payment_model.php`, `source-refs/sanmopia_web/application/controllers/api/Payment.php:31-33`	`pricing_settlement / CustomerPaymentInstruction`, `PaymentProviderApprovalRequest`	Partial	`CustomerPaymentInstruction` chosen from `PaymentProductPlan`, not raw payment-type flags; freeze purpose, amount, allowed method, route, fee, receipt, and settlement participation before provider handoff. Source still reads KCP `good_mny` from request data despite the inline warning that amount/return URL should come from server session. 2026-07-05 backend follow-up: `ReservationPaymentWorkflowHandler` rejects verified provider results whose returned amount differs from the frozen workflow command amount, blocks approved-charge finalization, blocks settlement continuation, and records a failed workflow reason. Remaining proof: bind every pre-registration and webhook entrypoint to the frozen backend amount for deposit, balance, pre-reservation, coupon, and payment-change payments.
`source-refs/sanmopia_web/application/models/Payment_model.php` legacy gateway refund/coupon paths	`pricing_settlement / payment_refund`	Partial	Kill Bill-backed `CancellationRefundSaga` linking reservation state, coupon/benefit restore, provider events, receipt artifact, ledger reversal, partial refund, and operator override.
`source-refs/sanmopia-admin/application/controllers/ajax/Reservation.php`, `PAYMENT_CHANGE_TB`	`pricing_settlement / payment_change_adjustment`	Partial	Frozen `PaymentChangeAdjustmentAmountBreakdown`, workflow status projection, provider event linkage, settlement continuation, and no operator-side recompute.
`source-refs/sanmopia-admin/application/controllers/Calculate.php`, `source-refs/sanmopia-admin/application/models/Payment_model.php`	`pricing_settlement / settlement_statement`	Partial	`SettlementStatementKind`, typed line contexts, effective-dated amount/date policies for external counterparties (source evidence includes Danbi/Danbee), branch, headquarters, inter-office, and repair statements.
`source-refs/sanmopia-admin/static/js/form_reservation_list.js`, `source-refs/sanmopia-admin/application/controllers/DataRoom.php`	`pricing_settlement / settlement_data_room`	Partial	Persisted `ArtifactRequest`, repair/download state, signed URL refresh, export audit, and no hidden iframe/raw GET download handoff.
`source-refs/sanmopia-admin/application/models/Matching_model.php`	`caregiver_assignment / caregiver_matching`	Partial	`CandidateSnapshot -> AssignmentDecision` with distance, branch scope, pet, schedule, grade, workload, and deterministic tie-breaker evidence.
`source-refs/sanmopia-admin/application/models/Matching_model.php:62-118`, `:144-172`, `:724-855`	`caregiver_assignment / CaregiverCandidateOrderingPolicy`, `CaregiverCandidateRecommendationSet`	Partial	Backend commit `05832cd` canonicalizes `CaregiverCandidateOrderingPolicy` over the older generic ranking name while keeping `CandidateRankingPolicy` and `CandidateRankingPolicyPayload` as compatibility aliases. The policy freezes score, distance, travel-duration, deterministic tie-breaker component order, source evidence keys, and replacement for source `RAND(userId)` / `RAND(reservationId)` ties. Backend commit `f07313b` adds `CaregiverCandidateRecommendationSet`, Pydantic payload roundtrip, Supabase table `sanmopia_caregiver_candidate_recommendation_sets`, repository save/load methods, and focused tests. Recommendation-set persistence freezes reservation revision, service dates, branch/class/search scopes, candidate limit, optimization input, optimization decision, ranked/excluded counts, and full snapshot payload. Existing `CaregiverCandidateSnapshot` rows keep pet fact, schedule proof, score components, distance/travel evidence, tie seed, and provider result snapshot. 2026-07-09 backend follow-up: OR-Tools assignment optimization now applies deterministic score-tie ordering by policy score, known/near distance, then caregiver id, so equal-score assignment plans no longer depend on solver tie behavior. 2026-07-09 backend follow-up 2: provider-unavailable and provider-fallback travel evidence now exclude candidates before ranking with stable `provider_unavailable` / `provider_fallback_used` reason codes; measured duration-only evidence can still rank with an explicit missing-distance penalty of zero. Remaining work: remove raw SQL search/date interpolation in adapters, persist any external provider freshness repair decisions needed by runtime, and bind final assignment API/UI to ordered recommendation sets.
`source-refs/sanmopia-manager/application/helpers/salary_helper.php`	`pricing_settlement / caregiver_compensation`	Partial	Payout-ready `CaregiverPayoutInstruction`, role/handoff payout slot projection, grade snapshot, assignment term, attendance facts, and no read-time salary recompute.
`source-refs/sanmopia-admin/application/views/manager/manager_pay_detail.php:4-115`, `:627-639`; `source-refs/sanmopia-admin/static/js/manager/manager_pay_detail.js:14-24`, `:75-86`, `:155-260`; `source-refs/sanmopia-admin/application/controllers/Manager.php:1007-1008`, `:1133-1183`, `:1225-1235`, `:1300-1335`; `source-refs/sanmopia-admin/application/models/Reservation_model.php:2453-2768`, `:2880-2964`, `:2945-3041`, `:3095-3147`; `source-refs/sanmopia-admin/application/models/Reservation_manager_salary_model.php:21-52`, `:112-170`	`pricing_settlement / AdminCaregiverPayoutStatementProjection`, `CaregiverPayoutAdjustmentCommand`, `CaregiverPayoutCompletionCommand`, `CaregiverPayoutCompletionAmountGuard`, `CaregiverTaxElection`, `CaregiverPayoutMemoRevision`, `ReservationFinanceSettlementCompletionGate`	Partial	Admin salary UX recomputes service weeks/days, weekend/holiday days, rental delivery fee `10000`, additional service totals, voucher custom pay, service-balance overrides, before/after caregiver pay, and tax amount in PHP and JS with inconsistent rounding (`round`/`floor`). UI completion posts the visible after-salary value and tax type, but the legacy `salary_complete` path dispatches to a model method that only flips main/sub payout status, stamps deposit timestamps, and repair-creates a missing payout row; amount/tax changes are separate save commands and completion can auto-move the reservation from settlement to done based on raw payout/service-balance flags. Backend must own payout statement projection, adjustment/receipt commands, role slot key, tax election, completion amount guard, append-only memo/reason audit, mutation proof, idempotency, and settlement-completion gate refresh; frontend/admin-entered values are diagnostics until persisted as revisioned payout facts.
`source-refs/sanmopia-admin/application/models/Manager_model.php`, `source-refs/sanmopia-admin/application/models/Manager_evaluation_model.php`	`caregiver_performance_recognition`	Partial	`CaregiverGradeSnapshot` linked to matching, assignment, quote, payout, effective season/window, and operator audit.
`source-refs/sanmopia-admin/application/controllers/Manager.php:174-205`, `:345-432`, `:535-542`	`caregiver_profile / caregiver_credential_restriction_workflow`, `caregiver_assignment / caregiver_availability_exception`	Pending	Admin profile edits, branch score clamping, career/education/health evidence, and denied work windows need revisioned commands with actor scope, media artifact grant, effective dates, score-cap policy, assignment invalidation, and approval/audit state. Source POST fields and mutable attachment names must not become target contracts.
`source-refs/sanmopia-admin/application/controllers/Manager.php:198-205`, `:234-240`, `:1653-1658`; `source-refs/sanmopia-admin/application/models/Manager_model.php:1618-1627`; `source-refs/sanmopia-admin/application/models/Manager_evaluation_model.php:526-528`	`caregiver_performance_recognition / CaregiverProfileScoreRevisionPolicy`, `CaregiverProfileScoreRevisionPlan`, `CaregiverProfileGradeScoreRevision`	Backend foundation + contract	Backend commit `baa1a1a` moves caregiver profile score save into `caregiver_performance_recognition/features/caregiver_scorecard`. `CaregiverProfileScoreRevisionPolicy` now freezes branch score floor `-50`, HQ/Danbee score floor `-100`, configured max-score policy snapshots, old/new caregiver grade-score basis, matching invalidation, and payout-projection invalidation. `PlanCaregiverProfileScoreRevisionPayload` rejects source fields such as `GRADE_SCORE`, `ADD_SCORE`, `OLD_MANAGER_FL`, `manager_score_branch`, and `manager_score_danbee`; UI submitted values are request facts only. Source bug where Danbee max clamp compares `score_branch` stays source evidence only; modern policy compares the correct HQ submitted score. Remaining work: persist score revision plan/audit with actor/reason/expected revision, add explicit `CaregiverClassChangeCommand`, emit matching/payout invalidation events, and bind admin profile save/runtime APIs.
`source-refs/sanmopia-admin/application/controllers/ajax/ManagerEvaluation.php:132-141`, `:157-190`, `:195-224`; `source-refs/sanmopia-admin/application/models/Manager_evaluation_model.php:614-724`, `:735-747`	`caregiver_performance_recognition / CaregiverEvaluationCappedScoreLedger`, `CaregiverPerformanceScorecard`	Backend foundation + contract	Backend commit `a07cc1f` adds `CaregiverEvaluationCappedScoreLedger`, `CaregiverEvaluationCappedScoreLedgerPolicy`, `ProjectCaregiverEvaluationCappedScoreLedgerPayload`, and `CaregiverEvaluationCappedScoreLedgerReadModel`. The backend now sorts evaluation score facts by `applied_on` then `fact_code`, reuses `CaregiverScorecardCapPolicy` for per-category and monthly-career/other-working combined caps, preserves `original_score`, `capped_score`, `score_before`, `score_after`, correction facts, source revision key, source evidence keys, and rejects legacy ajax/display fields such as `SCORE`, `MAX_SCORE`, `APPLY_DT`, `BEFORE_SCORE`, and `AFTER_SCORE`. Remaining work: Supabase ledger persistence, scorecard projection read API, grade/class recalculation workflow binding, and matching/payout invalidation consumers.
`source-refs/sanmopia-admin/application/models/Manager_evaluation_model.php:436-448`, `:458-487`, `:502-511`; `source-refs/sanmopia-admin/application/controllers/ajax/ManagerEvaluation.php:21-28`, `:30-47`, `:50-106`; `source-refs/sanmopia-admin/static/js/manager_evaluation/manager_evaluation.js:22-140`	`caregiver_performance_recognition / RecordCaregiverEvaluationScoreCommand`, `CaregiverEvaluationScoreEntry`, `CaregiverPerformanceScorecardWorklistQuery`	Backend foundation + contract	Backend commit `117a6f3` adds `RecordCaregiverEvaluationScoreCommand`, `CaregiverEvaluationScoreEntry`, `RecordCaregiverEvaluationScoreDecision`, `CaregiverEvaluationScoreRecordingPolicy`, `RecordCaregiverEvaluationScorePayload`, and `RecordCaregiverEvaluationScoreDecisionPayload`. Backend commit `200d67c` adds `CaregiverPerformanceScorecardWorklistQuery`, typed worklist sort/search/page enums, `CaregiverPerformanceScorecardWorklistSearchPolicy`, `CaregiverPerformanceScorecardWorklistRow`, `CaregiverPerformanceScorecardWorklist`, `CaregiverPerformanceScorecardWorklistPolicy`, and Pydantic payloads. The write command freezes actor, reason, expected scorecard revision, idempotency key, source reference key/value, source evidence keys, score fact, projected capped ledger, next scorecard revision, and matching/payout projection invalidation flags. The worklist now owns backend filters, allowed sort/search fields, page offset/size, next page token, row keys, record counts, and phone-search policy. Legacy write/query/DataTables fields such as `scoreType`, `referenceId`, `applyDate`, `draw`, `start`, `length`, `order`, `search`, `MANAGER_ID`, `SCORE`, `SCORE_BY_USER`, and `SELECT` are rejected at the contract boundary. Remaining work: Supabase append-only persistence, duplicate idempotency enforcement against stored rows, SQL worklist adapter, SpiceDB read grant binding, and runtime API binding.
`source-refs/sanmopia-admin/static/js/manager_evaluation/manager_evaluation.js:142-293`; `source-refs/sanmopia-admin/application/controllers/cli/Manager.php:37-120`, `:126-237`; `source-refs/sanmopia-admin/application/controllers/Manager.php:1633-1698`; `source-refs/sanmopia-admin/application/models/Manager_model.php:2467-2475`	`caregiver_performance_recognition / CaregiverScorecardDetailReadModel`, `CaregiverEvaluationScoreBackfillCommand`, `CaregiverClassChangeProposal`, `CaregiverGradeRecalculationWorkflow`, `CaregiverScoreSummarySnapshot`	Pending	Admin UI parses score text, recomputes max caps, derives service-day/age/education buckets, and cron writes monthly/other-working/age rows before recalculating class thresholds while skipping premium caregivers. Modern backend must own detail read model, source-score backfill command, class-change proposal/audit, premium exclusion reason, manager-list score summary snapshot, and scheduled rerun idempotency. UI bucket parsing and direct class writes are source evidence only.
`source-refs/sanmopia_web/application/views/mypage/reservation_document.php`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php`	`document_reporting / printable_document`	Partial	`ReservationDocumentCatalog`, `PrintableTemplateRegistry`, stored render artifacts, typed document keys, A4 HTML/PDF rendering, and no numeric document id/token URL leakage.
`source-refs/sanmopia_web/application/views/mypage/reservation_receipt.php:37-45`, `source-refs/sanmopia_web/application/views/mypage/reservation_receipt.php:85-103`, `source-refs/sanmopia_web/application/views/mypage/reservation_receipt.php:121-127`, `source-refs/sanmopia-admin/application/views/calculate_detail.php:560-601`, `source-refs/sanmopia-admin/application/views/calculate_detail.php:620-624`, `source-refs/sanmopia-admin/application/views/calculate_detail.php:654-703`, and `source-refs/sanmopia-admin/application/views/calculate_detail.php:834-883`	`pricing_settlement / CustomerPaymentReceiptProjection`, `document_reporting / CustomerReceiptArtifact`, `document_reporting / CustomerReceiptArtifactRevocationAfterRefund`, `pricing_settlement / SettlementReceiptLinkProjectionRefresh`	Partial	Legacy mother receipt and branch/HQ settlement detail screens build KCP bill URLs from mutable local payment/coupon rows, provider JSON/order ids, transaction ids, pay method, and local `PRICE`; the mother page even allows receipt opening for status `환불`. After provider refund or paid-row transition, backend must refresh receipt-link projections, revoke/reissue stale customer receipt artifacts, and refresh branch/HQ settlement receipt links from immutable payment/refund ledger snapshots before exposing bill URLs. Remaining proof: projection refresh worker consumption after `ProviderRefundResultEvent`/`PaymentRefundPaidRowTransitionDecision`, receipt artifact revocation/read-model persistence, and settlement receipt-link refresh tied to reversal lines.
`source-refs/sanmopia_web/application/controllers/api/Service.php` emergency/contact relation fallback	`member_management / family_account`	Partial	`ReservationPartyAuthoritySnapshot` for mother, sponsor, payer, emergency contact, contact-only viewer, refund authority, and document visibility.
Legacy UI price/status flags: `step3.js data-price`, `retc.php PRICE_TABLE`, `calculate_detail.js data-price`, old Astro payment/report/document buckets	Backend projections across `pricing_settlement`, `reservation_operations`, `document_reporting`	Pending	`CustomerPaymentActionProjection`, `MotherVisibleChargeSnapshot`, `CustomerReportObligationProjection`, and `PublicFeeGuideCatalogProjection`; frontend must never sum money or infer workflow state from raw rows.
`source-refs/sanmopia_web/application/views/shop/coupon_list.php:58-76`, `:102-124`, `:155-177`, `:392-414`	`customer_engagement / gift_coupon_offer_catalog`, `pricing_settlement / gift_coupon_payment_product_plan`	Partial	Gift-coupon purchase offers still need backend catalog rows for free/custom amount offers and fixed service/week offers, with amount bounds, selected offer code, purchaser/recipient authority, and refund policy. Backend stage proof now freezes payment product plan, settlement line template, and fulfillment side effects before provider handoff via `pnpm supabase:smoke:stage:gift-coupon-closeout-side-effects`; UI `custom-price` and `data-price` buttons are source evidence only.
`pre_reservation_detail.js`, `pre_reservation_detail.php`, source statuses `15/16/17/18`	`reservation_operations / pre_reservation_conversion`	Partial	`PreReservationConversionWorkspace` with conversion intent, payment instruction, save journal, return-state token, and stale-save conflict handling.
`feeguide.js`, `basePrice.js`, `priceCaculation.js`, `priceList.js`, old Astro fee-guide calculator	`pricing_settlement / public_fee_guide_catalog`	Partial	`PublicFeeGuideCatalogProjection` backed by effective-dated price catalog rows; public calculators read backend projections only.
`ManageSystem.php`, `holiday_list.js`, `reservation_calendar.js`, `step3.js`, `Report_model.php` holiday branches	`service_calendar / holiday_policy_execution`	Partial	`HolidayPolicyExecutionAndImpactInvalidation` covering add/revise/withdraw, substitute-of, branch closure, and quote/matching/report/settlement invalidation.
`DataRoom.php`, `Calculate.php`, `Spreadsheet_model.php:3741-3914`, `form_reservation_list.js`	`pricing_settlement / settlement_collection_export_repository`	Partial	`SettlementCollectionExportRepository` with external-counterparty, HQ, inter-office, and reservation-document export readers, frozen dataset revision, column contract, and signed grant.
`Matching_model.php`, `Reservation_manager_trans_info_model.php`, `Manager_model.php`, `manager_pay_detail.js`	`caregiver_assignment / assignment_decision_evidence`, `pricing_settlement / caregiver_payout_statement`	Partial	`CaregiverAssignmentDecisionEvidence` and `CaregiverPayoutStatementProjection`; separate travel/conflict/override evidence from shared payout projection.
Sponsor, payer, emergency-contact, refund-recipient, document-visibility source branches	`member_management / reservation_party_authority`, `pricing_settlement / refund_side_effect_ordering`	Partial	`ReservationPartyAuthoritySnapshot` and `RefundRecipientAndSideEffectOrdering` with consent, contact-only access, refund recipient, and document visibility rules.
`static/dist/excel/type*.xlsx`, old PDF/static document variants, document numeric ids	`document_reporting / printable_template_version_manifest`	Partial	`PrintableTemplateVersionManifestCompleteness` mapping document kind, version, file source, service eligibility, render format, and A4 output contract.
`cli/Price.php`, `Spreadsheet_model.php:4807-5400`, `sanmopia-price-table/*.xlsx`	`pricing_settlement / price_catalog_import_execution_audit`	Partial	`PriceCatalogImportExecutionAudit` with batch, dry-run issue report, rollback/repair, private-care/general coverage, and private artifact evidence.
`source-refs/sanmopia-admin/application/views/reservation_status/reservation_add.php:273`, `source-refs/sanmopia-admin/static/js/reservation_status/reservation_add.js:1519`, `source-refs/sanmopia_web/application/controllers/api/Service.php:346`, `source-refs/sanmopia_web/application/models/Reservation_model.php:2526`, `source-refs/sanmopia-admin/application/controllers/Reservation.php:1749`, `source-refs/sanmopia_web/application/models/Reservation_model.php:1181`, `source-refs/sanmopia-admin/application/models/Payment_model.php:436` regional/support branches	`pricing_settlement / regional_benefit_policy`, `reservation_operations / service_calendar_quote_impact`	Partial	Backend `RegionalBenefitRule` metadata now carries `regional_benefit_profile_key`, `service_day_bonus_count`, and `settlement_participation_code` so residency support profiles can drive service-day bonus and settlement participation without UI/admin string branches. `FinalizeReservationChargeWithRegionalBenefitHandler` now resolves and freezes the decision for price-summary charge finalization. Remaining work: runtime reservation entrypoints, service calendar, payment-conversion, and settlement must consume the same decision/snapshot path.
`source-refs/sanmopia_web/application/controllers/api/Account.php`, `source-refs/sanmopia_web/application/controllers/Mall.php`, `source-refs/sanmopia_web/application/models/User_model.php`	`member_management / customer_identity_profile`, `customer_engagement / external_commerce_member_link`	Partial	Profile, security, marketing consent, FCM token, social completion, shop referral, gift-coupon claim, rollback, and privacy lifecycle must be separate backend facts.
`source-refs/sanmopia_web/application/controllers/api/Service.php` service/intake paths	`reservation_operations / customer_reservation_intake_draft`	Partial	Revisioned intake draft, branch service-area decision, care-plan invalidation, rental selection, named-caregiver carryover, continuation, and Restate workflow state; no source `PROCESS_NO` or browser price/version mutation.
`source-refs/sanmopia_web/application/controllers/api/Reservation.php`, `source-refs/sanmopia_web/application/controllers/api/Payment.php`, `source-refs/sanmopia_web/application/models/User_model.php`	`reservation_operations / customer_reservation_intent`, `pricing_settlement / customer_payment_instruction`, `document_reporting / customer_document_download_grant`	Partial	Birth/service correction, change/cancel/stop/extension, branch notification routing, deposit/balance/coupon/pre-reservation/change-payment, two-hour document-token replacement, and signed Storage grant are backend commands/projections.
`source-refs/sanmopia-manager/application/controllers/Report.php`, `source-refs/sanmopia-manager/application/controllers/Service.php`, `source-refs/sanmopia-manager/application/controllers/Attendance.php`, `source-refs/sanmopia-manager/application/models/Notify_model.php`	`care_delivery / care_delivery_obligation`, `customer_engagement / report_service_notification`	Partial	First/progress/last reports, service records, attendance, main/sub caregiver role, duplicate guards, newborn bootstrap, dispatch attempts, and mother-visible notification audit must be durable backend obligations.
`source-refs/sanmopia-admin/application/models/Statistics_model.php`, `source-refs/sanmopia-admin/application/controllers/Datatable.php`, `source-refs/sanmopia-admin/static/js/statistics/*`	`business_reporting / admin_analytics_catalog`	Partial	Versioned report definitions, filters, metric definitions, branch visibility, frozen totals, export artifact handoff, and operator audit; UI tables must not own metric formulas.
`source-refs/sanmopia-admin/application/controllers/OfficeManagement.php`, `source-refs/sanmopia-admin/application/models/Branch_model.php`, branch login sources	`branch_operations / office_profile`, `operator_access / branch_login_audit`	Partial	Branch profile, lifecycle, operator credential, membership fee, settlement accounts, brand assets, service area, credential rotation, login audit, and stale-save conflict recovery need backend commands and SpiceDB/OPA gates.
`source-refs/sanmopia-admin/application/controllers/Promotion.php`, `source-refs/sanmopia-admin/application/models/Coupon_model.php`, `source-refs/sanmopia-admin/application/models/Momfirst_model.php`, customer shop paths	`customer_engagement / promotion_entitlement`, `pricing_settlement / gift_fulfillment`, `document_reporting / partner_benefit_result_artifact`	Partial	Coupon lineage, gift fulfillment, Momfirst/Clean delivery batches, result artifacts, download grants, audience policy, suppression, retry, and repair audit need backend-owned workflow state.
`source-refs/sanmopia_web/application/controllers/MyReservation.php:21-190`	`reservation_operations / CustomerReservationLifecycleSnapshot`	Partial	Customer reservation lifecycle must project proceeding/history buckets, pre-reservation detail routing, report/add-date/continue/service-balance overlays, and virtual-account prompts from backend policy, not portal status/payment maps. Domain symbols now use snapshot/entry/report-obligation/care-team language; remaining gate is application path and generated contract alias migration away from `view`, `card_display`, `report_presentation`, and `caregiver_display`.
`source-refs/sanmopia_web/application/views/mypage/item/reservation_func_btn.php:1-190`, `source-refs/sanmopia_web/application/views/mypage/item/reservation_detail_func_btn.php:1-210`	`reservation_operations / CustomerActionAvailabilityPolicy`	Partial	Customer action availability must cover list/detail actions: reservation payment, delivery info input, pre-reservation conversion, report writing, cancellation, extension, rescheduling, more-info, service-end gates, 15-day extension window, stop/change/payment/report buttons, hidden states, disabled reasons, and command targets.
`source-refs/sanmopia_web/static/js/mypage/reservation.js:336-421`	`reservation_operations / CustomerActionCommand`	Partial	Customer action commands must own request copy, required reason validation, instant-cancel result, idempotency, and post-command navigation intent for cancel/change/stop instead of browser JS deciding success behavior.
`source-refs/sanmopia-admin/application/views/reservation_status/reservation_detail.php:80-270`	`reservation_operations / ReservationActorCapabilityProjection`	Partial	Backend foundation now splits HeadOfficeManager and BranchOwner reservation-stage capabilities, including offline cancel authority, branch-disallowed offline selection, pre-reservation status subsets, save locks, disabled reasons, and visible transition options. Remaining gates: bind Supabase Auth actor identity, SpiceDB relationship facts, OPA decisions, field visibility, command targets, audit context, and API/read adapters.
`source-refs/sanmopia-admin/application/controllers/Reservation.php:650-1020`, `source-refs/sanmopia-admin/static/js/reservation_status/reservation_detail.js:270-342`	`reservation_operations / ReservationCollaborationConflictLog`, `ReservationCollaborationWorkspace`	Partial	Broad reservation detail saves must become changed-field commits with expected revision, workspace id, actor role/profile, attempted mutation groups, conflicting field paths, latest audit event, conflict diff, realtime invalidation state, resolution, backend navigation intent, and return-state token.
`source-refs/sanmopia-admin/application/models/Reservation_model.php:1768-1955`	`reservation_operations / ReservationStateTransitionCatalog`	Partial	Reservation state transitions must preserve side effects: confirm timestamp, settlement/pay-info creation, central-branch payment insertion, KCP refund/coupon reset on cancel, stop coupon reset only on real status change, and consult/extension notifications.
`source-refs/sanmopia-manager/application/controllers/Schedule.php:27-75`, `source-refs/sanmopia-manager/application/views/schedule/schedule_info.php:136-345`	`care_delivery / CaregiverWorkScheduleProjection`, `CaregiverActionAvailabilityProjection`	Partial	Caregiver schedule/action projections must enforce assignment ownership, 90-day access window, main/assistant role, delivery/preference/voucher facts, service/report task counts, payout state, balance confirmation, assistant payout confirmation, sequential service-record writing, report writing, completed states, and backend-owned route/date targets.
`source-refs/sanmopia_web/application/controllers/api/Payment.php:80-215`, `source-refs/sanmopia_web/application/controllers/api/Payment.php:250-320`, `source-refs/sanmopia_web/application/controllers/api/Payment.php:580-645`	`member_management / ReservationPartyAuthoritySnapshot`, `pricing_settlement / PayerAndGiftRecipientProjection`, `PaymentCommunicationDispatchRoute`	Partial	Payment recipient/routing policy must distinguish mother, payer/family sponsor, branch director, gift-coupon buyer, receiver, phone-only receiver, virtual-account completion notices, pre-reservation payment notices, SMS fallback, secondary branch contact, and branch-id exception as backend snapshots and communication routes.
`source-refs/sanmopia-admin/application/models/Data_room_model.php:25-80`, `source-refs/sanmopia-admin/application/controllers/DataRoom.php:119-212`	`document_reporting / BranchResourcePostAudiencePolicy`	Partial	Branch resource posts need backend send/receive/HQ branch-36/null visibility policy, pinned ordering, attachment-delete audit, branch filter, write/delete commands, and SpiceDB/OPA checks.
`source-refs/sanmopia-admin/application/controllers/cli/Excel.php:120-180`, `source-refs/sanmopia-admin/application/controllers/cli/Excel.php:405-430`	`pricing_settlement / SourceExcelRepairWorkbookCommand`, `operator_access / BranchLoginAuditExport`	Partial	Legacy Excel repair/export CLI needs typed repair/export requests with dataset revision, actor, reason, idempotency, source workbook hash, artifact grant, and audit.
`source-refs/sanmopia-admin/application/controllers/Administrator.php:174-225`	`operator_access / LegacyMaintenanceCommandGate`, `migration_governance / SourceRepairCommandCatalog`	Partial	Admin `test*`, branch-token, update-date, settlement-backfill, complete-backfill, and coupon-reset endpoints need protected repair commands, dry-run, expected revision, actor/reason audit, and no public test route.
`source-refs/sanmopia-admin/application/controllers/Api.php:5-43`	`customer_engagement / PromotionEntitlementAdminCancellation`	Partial	Admin coupon/Momfirst deletion must become entitlement cancellation command with actor, reason, linked payment/settlement/fulfillment side effects, restore, and repair ledger.
`source-refs/sanmopia_web/application/helpers/utility_helper.php:666-696`, `source-refs/sanmopia_web/application/helpers/utility_helper.php:703-755`	`document_reporting / ArtifactDownloadResponsePolicy`, `platform / LegacyRealtimePushBridge`	Missing	`force_download_by` and `push_to` have no confirmed call sites yet. Either mark as dead-source carryover after proof, or migrate CSV/XML header/BOM policy and region-prefixed socket publish semantics into backend document/platform policies with retry and audit.

CaveCrew Source Gap Delta 2026-07-05

The explorer pass below is not a source-code copy list. It is a source-evidence delta for backend abstractions that still need stronger modern slices.

Priority	Source evidence	Modern target	Status	Required improvement
P0	`source-refs/sanmopia-admin/application/views/reservation_status/reservation_detail.php:86-99`, `:247-261`; `source-refs/sanmopia-admin/application/controllers/Reservation.php:420-431`	`reservation_operations / ReservationActorCapabilityProjection`	Partial	Backend foundation exists; next bind Supabase Auth actor, SpiceDB relation, OPA result, field visibility, command targets, and audit context.
P0	`source-refs/sanmopia-admin/application/models/Reservation_model.php:1769-1916`; `source-refs/sanmopia_web/application/models/Reservation_model.php:989-1112`	`reservation_operations / ReservationStateTransitionPolicy`, `ReservationLifecycleSideEffectPlan`, `ReservationOperationFollowUpWorkflow`; `pricing_settlement / ReservationPromotionSideEffectPlan`	Partial	Backend foundation now maps accepted transition follow-up actions into typed side-effect work items for audit, customer notification, refund closeout, refund completion barrier, benefit release, branch settlement opening, and financial lifecycle closeout. Remaining gates: persist plan snapshots, bind Restate workflow dispatch, execute pricing/customer-engagement side effects idempotently, and expose repair/read models. Source status numbers and provider-specific payment names stay in adapters/evidence, not target components.
P0	`source-refs/sanmopia-admin/application/models/Reservation_model.php:1769-1916`; `source-refs/sanmopia-admin/application/models/Reservation_model.php:1980-2140`; `source-refs/sanmopia_web/application/controllers/api/Reservation.php:115-239`; `source-refs/sanmopia_web/application/models/Payment_model.php:101-441`	`reservation_orchestration / ReservationLifecycleSideEffectExecution`, `reservation_operations / ReservationLifecycleSideEffectPlan`	Partial	Execution layer now enriches plan work items with `targetFeature`, `commandKind`, `sourceEvidenceRef`, persisted preconditions, compensation, execution status, retry/dead-letter/repair state, Supabase-first persistence, and Restate dispatch. Refund closeout now emits a separate `payment_refund_completion_barrier` execution item requiring terminal provider refund evidence or zero-refund fact before downstream benefit/settlement work can complete. Remaining gates: worker execution, provider-event ingestion binding, zero-refund fact persistence, and operator repair/read projections beyond internal provider-refund planning/execution/result-recording persistence. See Reservation Lifecycle Side Effect Execution.
P0	`source-refs/sanmopia_web/application/models/Payment_model.php:383-441`; `source-refs/sanmopia_web/application/controllers/api/Payment.php:80-215`, `:250-320`, `:537-545`, `:580-645`; `source-refs/sanmopia_web/application/models/Payment_model.php:775-843`	`pricing_settlement / PaymentAdjustmentQuote`, `PaymentChangeRefundLink`, `ProviderPartialRefundCapability`, `PreReservationPaymentCloseout`, `PreReservationCouponOverCreditPolicy`, `PaymentCloseout`; `promotion_entitlement / PromotionEntitlementOutbox`	Partial	Kill Bill-backed closeout must centralize refund, partial refund, custom charge, coupon restore, provider capability, zero-provider-payment closeout, and settlement continuation. 2026-07-05 backend follow-up: `PaymentChangeRefundLink` now enters at the Pydantic application boundary, flows into Pydantic-free `PaymentRefundIntent` and append-only `PartialRefund`, persists as queryable `sanmopia_payment_refund_ledger_entries.payment_change_adjustment_id` with a fallback read from historical provider-command properties, and is exposed through `POST /reservation-cancellation-refunds` plus TS contract validators. `PreReservationCouponOverCreditPolicy` now centralizes legacy `realPrePrice = max(required - coupon, 0)` and over-credit point/shop grant planning with a versioned rule instead of UI/controller arithmetic. 2026-07-07 sidecar: zero-payable pre-reservation must close without a provider call, virtual-account pre-reservation must stay waiting until a deposit fact, and over-credit point/shop grants must be emitted from an entitlement outbox after payment-record persistence; UI/controller `realPrePrice` and over-credit math are evidence only. Remaining work: provider partial-cancel capability events, zero-gateway-refund quote decisions, pre-reservation payment record persistence, pre-reservation entitlement outbox closeout, virtual-account waiting/deposit closeout, and reservation closeout workflow binding.
P0	`source-refs/sanmopia-admin/static/js/reservation_status/payment_change.js:93`; `source-refs/sanmopia-admin/application/models/Payment_model.php:4507-4511`; `source-refs/sanmopia-admin/application/models/Reservation_model.php:1861-1866`; `source-refs/sanmopia_web/static/js/mypage/reservation_changePayment.js:43`; `source-refs/sanmopia_web/application/views/modal/modal_change_payment.php:1-18`	`pricing_settlement / PaymentChangeAdjustmentCloseout`, `PaymentChangeRefundLink`, `ChargeQuoteSnapshot`, `ChargeSummaryProjection`	Partial	Source lets operators type closeout amount/status and lets browser/view code recompute conversion amount, coupon, and pre-reservation deduction. Backend must keep mutable operator completion, immutable paid amount, refund link, charge snapshot, and provider refund fact separate. 2026-07-07 follow-up: `CloseLatestZeroPayablePaymentChangeAdjustmentCommand`, `POST /reservation-payment-change-adjustments/{reservationBookingId}/zero-payable-closeouts`, and `PaymentChangeAdjustmentZeroPayableCloseoutPayload` now close zero mother-payable adjustments through a backend-owned receipt (`zero_payable_closeout`) without KCP/Kill Bill provider wait, reject negative refund cases, and request settlement continuation through the paid-adjustment path. Remaining work: charge-summary projection persistence plus provider/refund workflow execution for positive and credit/refund cases.
P0	`source-refs/sanmopia_web/application/models/Payment_model.php:861-871`; `source-refs/sanmopia-admin/application/models/Payment_model.php:4431-4440`; `source-refs/sanmopia-admin/application/models/Reservation_model.php:1861-1870`; `source-refs/sanmopia-admin/application/models/Payment_model.php:4451-4461`	`pricing_settlement / PaymentChangeRefundEligibleAdjustmentSelectionPolicy`, `PaymentChangeRefundIntent`	Backend foundation	Source inserts new unpaid payment-change drafts while preserving older paid rows, but cancellation refund reads only the latest row by id and refunds only when that row has provider context. A later unpaid draft can hide an older paid payment-change receipt from cancellation refund. 2026-07-07 backend follow-up: `PaymentChangeRefundEligibleAdjustmentSelectionPolicy` now scans all paid/completed provider-receipted payment-change adjustments by reservation, excludes unpaid drafts, zero-payable closeouts, other reservations, and already-refunded adjustment ids, and returns deterministic refund-eligible adjustment facts. Remaining work: wire Supabase selection into cancellation refund execution so one `PaymentChangeRefundIntent` is emitted per eligible adjustment.
P0	`source-refs/sanmopia-admin/application/models/Reservation_model.php:1873-1892`; `source-refs/sanmopia-admin/application/models/Coupon_model.php:63-157`, `:935-958`; `source-refs/sanmopia_web/application/models/Coupon_model.php:530-553`	`pricing_settlement / RefundSideEffectPlan`; `promotion_entitlement / EntitlementRestorationPlan`, `ActualServiceDayCouponPolicy`	Backend foundation + contract	Source cancel/stop directly reopens used coupons and hard-deletes/recreates product coupons from attendance-day bands. Backend already owns `ProductCouponResetPolicy`; commit `5dfff36` adds `ProductCouponResetContract` so stop/cancel reset is planned from actual service-day evidence, service-interruption kind, existing entitlement ids, versioned entitlement rules, and actual-service-day schedules. Contracts reject destructive source fields such as `COUPON_TB`, `USER_COUPON_TB`, `COUPON_ID_PK`, `COUPON_TYPE_CD_FK`, `PRODUCT1`, `PRODUCT2`, `DELETE_FL`, `PRICE`, `MANAGER_ATTENDANCE_TB`, `realServiceDay`, `사은품 1주 쿠폰`, and `사은품 2주 쿠폰`. Remaining work: persist reset plans/outbox in Supabase, bind refund/cancellation closeout workflow, map care-delivery attendance facts into `actual_service_days`, and expose repair/read APIs for entitlement revocation/reissue.
P0	`source-refs/sanmopia_web/application/models/Reservation_model.php:2526`, `:2546`, `:2577`, `:2627`; `source-refs/sanmopia_web/static/js/step3.js:477`, `:523`, `:890`; `source-refs/sanmopia-admin/static/js/reservation_status/reservation_add.js:2155`; `source-refs/sanmopia-admin/application/models/Manage_system_model.php:10-63`	`service_calendar / ServiceTermPolicy`, `HolidayCalendarRegistry`, `AdditionalServiceDaySelection`, `ServiceAreaCalendarProfile`	Backend foundation + contract	Source mixes one-week/two-week service math, voucher-day math, manual holiday rows, selected Saturday/holiday dates, hidden UI end dates, and hardcoded regional day additions. Backend domain already owns `ServiceTermPolicy`, `HolidayCalendarRegistry`, `AdditionalServiceDaySelection`, and `ServiceAreaCalendarProfile`. Backend contract commit `f095925` adds `application/service_calendar/features/service_term_policy` with strict Pydantic payloads for term planning, holiday entries, service-area profile registries, selected additional non-working days, and immutable term plan output. Contracts reject browser/PHP fields such as `saturday_list[]`, `holiday_list[]`, `is_wanju`, `add_sat_date`, `add_holi_date`, `HOLIDAY_DT_PK`, `SERVICE_DAY`, `serviceDay`, `토요일 추가`, `휴일 추가`, and `완주군`. Tach now explicitly fences `domain.service_calendar.features.service_term_policy` and its application contract. Remaining work: persist service-term plan snapshots in Supabase, bind booking/admin quote endpoints to `PlanServiceTermPayload`, connect additional-day charge quote policy, and migrate frontend/admin hidden end-date fields to backend snapshots only.
P0	`source-refs/sanmopia_web/application/models/Reservation_model.php:2051`, `:2091`, `:2473`; `source-refs/sanmopia_web/application/models/Manager_model.php:176`; `source-refs/sanmopia-admin/application/config/constants.php:127`; `source-refs/sanmopia-admin/application/models/Coupon_model.php:72`, `:99`	`reservation_operations / ReservationContinuationLink`, `ContinuationDraftConflictFact`, `ContinuationVoucherEligibilityDecision`, `ContinuationCaregiverCarryoverDecision`; `service_lifecycle / ServiceInterruptionPolicy`; `promotion_entitlement / ProductCouponResetPolicy`	Backend foundation + contract	Source extension creates linked reservations, blocks duplicate active extensions, rejects voucher-chain extension, and conditionally reuses the manager. Stop/cancel uses actual attendance rows for benefit reset. Backend commit `7d5db21` adds continuation draft eligibility and creation planning with source-status/table-field rejection, replaceable-writing-draft tracking, active/submitted duplicate blocking, idempotency, superseded draft id, copied-fact audit key, cloned-fact keys, and first-class continuation link output. Product coupon reset contract `5dfff36` covers actual-service-day entitlement recalculation. Remaining work: persist continuation draft plans and copied-fact audit rows in Supabase, bind booking/admin extension APIs, dispatch service-period/quote/matching invalidation, persist service interruption intervals, and connect promotion entitlement outbox execution.
P0	`source-refs/sanmopia_web/application/controllers/api/Service.php:323-325`; `source-refs/sanmopia_web/application/models/Reservation_model.php:2473-2501`	`reservation_operations / ContinuationVoucherEligibilityDecision`	Backend-backed foundation	Continuation voucher conversion must inspect the whole ancestor reservation chain, not just the current booking. Backend now adds a chain-fact decision, Pydantic payload, Supabase query columns, and TS/schema contract so UI cannot decide voucher continuation eligibility from a single row or source status code. Remaining work: bind booking/continuation command runtime to the decision and expose operator/customer reason copy.
P0	`source-refs/sanmopia_web/application/controllers/api/Service.php:329-332`	`reservation_operations / VoucherRecipientIdentityEligibilityDecision`	Backend-backed foundation	Source rejects voucher booking from resident-number back digit parity in controller code. Backend now evaluates only first back digit evidence, stores `redacted_identity_evidence_key`, reason code, source rule key, Supabase backend-owned decision row, Pydantic payload, and TS/schema decision contract. Raw resident-number fragments must not be persisted or exposed in public contract. Remaining work: bind voucher booking command runtime and operator/customer reason copy.
P0	`source-refs/sanmopia_web/application/controllers/api/Service.php:425-440`, `source-refs/sanmopia_web/application/controllers/api/Service.php:548-566`; `source-refs/sanmopia_web/application/models/Manager_model.php:176-198`	`reservation_operations / ContinuationCaregiverCarryoverDecision`	Backend-backed foundation	Continuation forces consulting and tries same-caregiver carryover only when prior manager exists and schedule check passes. Backend now maps source result `-1/-2/-3/manager_id` into typed reason codes `continuation_link_missing`, `prior_caregiver_missing`, `same_caregiver_schedule_conflict`, and `same_caregiver_available`, persists queryable carryover columns, and exposes TS/schema contract. Remaining work: bind runtime schedule reader and operator/customer copy.
P0	`source-refs/sanmopia-admin/application/controllers/Calculate.php:150-312`; `source-refs/sanmopia-admin/static/js/calculate_detail.js:20-323`; `source-refs/sanmopia-admin/application/models/Payment_model.php:554-561`, `:2861-2878`, `:2977-3051`, `:4302-4400`; `source-refs/sanmopia-admin/application/controllers/DataRoom.php:237-309`	`pricing_settlement / DanbiSettlementArchive`, `HeadquarterBranchSettlement`, `SettlementApprovalWorkflow`, `SettlementAdjustmentLine`, `SettlementDataRoomCollection`	Partial	Source collapses Danbi archive, branch-to-HQ settlement, HQ approval, branch confirmation, checkbox-paid rows, manual gift/additional service charges, memo/message fields, and archive export into mutable board CRUD. Target must separate ledger read models, workflow state, approval tasks, manual adjustment lines, branch/HQ visibility, expected revision, and audit diff.
P0	`source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:17`, `:3741`, `:3903`, `:4131`; `source-refs/sanmopia-admin/application/views/data_room/form_reservation_list.php:123`, `:207`; `source-refs/sanmopia-admin/static/js/data_room/form_reservation_list.js:225`; `source-refs/sanmopia-admin/application/controllers/DataRoom.php:119-212`, `:311`	`document_reporting / SettlementStatementGeneration`, `MaterialRoomDocumentRequest`, `BranchResourcePost`, `ReservationDocumentExportWorklist`, `DocumentArtifactGrant`	Partial	Source uses hardcoded XLSX template ids, hidden iframe POST downloads, temp zip/pdf/xlsx files, direct file delete/update, and weak download audit. Backend foundation now adds `ReservationDocumentExportWorklist`, `ReservationDocumentExportSelectionToken`, and Pydantic contracts so selected reservation ids, document definition keys, actor scope, and export artifact request use immutable backend fingerprints instead of mutable hidden iframe or raw GET parameters. Target still must bind DB-backed worklist queries, template eligibility, async render/export jobs, Supabase Storage signed grants, artifact checksum/retention, post attachment version history, soft delete, and download audit/rate limits.
P0	`source-refs/sanmopia-admin/application/models/Reservation_model.php:699-818`; `source-refs/sanmopia_web/application/models/Reservation_model.php:1165-1369`	`pricing_settlement / RegionalBenefitDecision`, `ReservationPriceVersionAndSubsidyAdjustment`	Partial	Subsidy, regional benefit, discount, support criteria, and price-version effects must be persisted as effective-dated decision facts.
P0	`source-refs/sanmopia_web/application/views/service/step1.php:188-214`; `source-refs/sanmopia_web/application/models/Reservation_model.php:314-374`; `source-refs/sanmopia_web/application/controllers/api/Service.php:70-86`	`member_management / ReservationPartyAuthoritySnapshot`	Backend/contract foundation	`ReservationPartyAuthoritySnapshot` now separates mother beneficiary, booker, payer, emergency contact, document viewer, refund recipient, and notification recipient with explicit `ReservationPartyAuthorityEvidence`; contact relation labels and phone-only contacts can be preserved as evidence but cannot grant document/refund/payment authority by themselves. `ReservationPartyAuthoritySnapshotPayload` now round-trips that vocabulary through a strict Pydantic boundary and rejects source relation text as role/authority. Remaining proof: Supabase persistence, booking/payment/refund/document command binding, public/internal API routes, and UI migration away from relation-text/phone ownership inference.
P0	`source-refs/sanmopia-admin/application/config/constants.php:116-137`; settlement eligibility source status use in reservation and settlement source files	`pricing_settlement / SettlementReservationLifecycleStatus`, `reservation_settlement_status_acl`	Partial	Settlement domain no longer owns source numeric reservation status values; `SettlementReservationLifecycleStatus` is semantic and source code conversion lives in application ACL. Remaining migration must wire Supabase/adapters through the ACL and remove numeric status mapping from refund, branch-settlement, and external-counterparty domain code.
P1	`source-refs/sanmopia-admin/application/controllers/Reservation.php:650-720`, `:940-1021`; `source-refs/sanmopia-admin/application/models/Reservation_model.php:3728-3740`; downstream consumers `source-refs/sanmopia_web/application/models/Report_model.php:312-322`, `:439-449`, `source-refs/sanmopia-admin/application/models/Statistics_model.php:215-230`, `:2581-2587`	`reservation_operations / ReservationCollaborationConflictLog`, `ChangedFieldCommit`; `business_reporting / ReservationStatusChangeFactProjection`	Partial	Replace broad before/after JSON with typed changed-field commits, expected revision, conflict diff, chosen winner, realtime invalidation, and return-state token. The legacy JSON diff is also report/metrics authority through `BEFORE_DATA`/`AFTER_DATA` string matching for stop/change facts, so reporting projections must bind typed reservation status/service-term events rather than parse UI-save audit blobs.
P1	`source-refs/sanmopia-admin/application/controllers/DataRoom.php:215-309`, `:389-408`; `source-refs/sanmopia-admin/application/models/Data_room_model.php:12-20`	`pricing_settlement / SettlementCollectionExportRepository`, `SettlementDataRoomArtifactBuildWorker`, `ExternalSettlementCounterpartyReadinessProjection`	Partial	Settlement data-room exports need frozen dataset revision, external-counterparty readiness, artifact build worker, signed grant, and repair history.
P1	`source-refs/sanmopia-manager/application/helpers/salary_helper.php:4-228`	`pricing_settlement / CaregiverPayoutStatementProjection`, `AdminCaregiverCompensationReadModel`	Partial	Shared admin/manager payout read model must freeze role slot, grade snapshot, attendance facts, tax election, adjustment, confirmation, and receipt state.
P1	`source-refs/sanmopia_web/application/models/Reservation_model.php:1091-1112`, `:3263-3273`; `source-refs/sanmopia-admin/application/models/Reservation_model.php:6180-6190`	`service_calendar / ServiceOccurrenceEvidenceRequirement`, `ServiceSuspensionInterval`, `ExtraServiceDateAnomalyAcknowledgement`	Partial	Holiday, interruption, substitute-day, and anomaly handling need occurrence evidence, acknowledgement, and quote/matching/report/refund/settlement invalidation.
P1	`source-refs/sanmopia-admin/application/models/Reservation_model.php:1769-1916`; `source-refs/sanmopia_web/application/models/Reservation_model.php:989-1037`	`pricing_settlement / ReservationPromotionSideEffectPlan`, `ProductCouponResetPolicy`, `ReservationCouponRestorePolicy`, `PromotionEntitlementOutbox`; `customer_engagement / BenefitFulfillmentCancellationOutbox`	Partial	Cancel/stop/refund side effects must become explicit promotion entitlement, benefit fulfillment, payment closeout, and communication decisions with idempotent outbox repair.
P1	`source-refs/sanmopia-admin/application/models/Branch_model.php:289-426`, `:602`; `source-refs/sanmopia_web/application/models/Reservation_model.php:2113-2137`, `:2239-2302`	`branch_operations / BranchServiceAreaDecisionRecorder`, `ServiceAreaCoverageProfile`; `reservation_operations / ReservationServiceAddressCoverageSnapshot`	Partial	Address and coverage decisions need frozen snapshots and effective-dated coverage profiles reused by booking, extension, transfer, pricing, matching, and audit. Possible, consultation-only, and impossible area rules must not remain mutable branch table reads at decision time.
P1	`source-refs/sanmopia_web/application/models/Branch_model.php:45-90`, `source-refs/sanmopia_web/application/models/Branch_model.php:93-139`; `source-refs/sanmopia-admin/application/models/Branch_model.php:369-401`; `source-refs/sanmopia_web/application/controllers/api/Service.php:46-53`	`branch_operations / BranchCoverageOverrideDecision`	Backend-backed foundation	Source first finds possible/consultation area, then any impossible row vetoes. Admin allows consultation/impossible only under an existing possible area. Modern branch policy now keeps unavailable > consultation-only > available precedence and adds `BranchCoverageOverrideDecision` with explicit available-parent rule id/revision proof, period coverage rejection, missing-parent rejection, and public contract/schema. Remaining work: expose runtime preflight endpoint, persist override decision evidence, and route admin rule editor through this decision before publication.
P1	`source-refs/sanmopia-manager/application/helpers/salary_helper.php:109-214`	`pricing_settlement / CaregiverPayoutPolicyProfile`, `CareTeamCompensationSlot`	Backend-backed foundation	Weekend/holiday additions, repeating effective-day options, voucher add-ons, tax election, custom service balance, primary caregiver custom pay, and assistant caregiver custom pay are now represented by `CaregiverPayoutPolicyProfile`, `CareTeamCompensationSlot`, and `CaregiverPayoutPolicyDecisionSnapshot` in backend domain/application contracts plus TS/schema contracts. Slot identity is `assignment_key + caregiver_role + handoff_order`, and final payable amount freezes override source so manager/admin UI cannot recompute from mutable `OPTION`, service-balance, or salary rows. Remaining work: persist decision snapshots with payout instructions and bind admin/manager/HQ screens to the frozen read model.
P1	`source-refs/sanmopia-manager/application/helpers/salary_helper.php:42-99`	`pricing_settlement / CaregiverVoucherAddOnTaxCutoverPolicy`	Backend-backed foundation	Voucher special/live-in add-on, tax category, 3.3% style withholding, and pre-`2022-03-29` after-tax cutover are now represented as a versioned policy plus frozen decision payload. Remaining work: bind runtime quote/payout statement builders to the decision and persist final statement snapshots.
P1	`source-refs/sanmopia-manager/application/helpers/salary_helper.php:67-160`	`pricing_settlement / CaregiverAdditionalServiceDayBasis`	Backend-backed foundation	Normal/customer-funded basis multiplier, voucher basis multiplier, service-day extension option lines, repeating per-effective-day option lines, voucher custom service balance override, and profile-based voucher add-on deduction are now represented as a versioned backend policy plus contract decision. Remaining work: bind quote/payout statement builders and persistence so admin/manager screens read the frozen decision instead of recalculating helper totals.
P1	`source-refs/sanmopia-manager/application/views/schedule/schedule_info.php:136-200`, `source-refs/sanmopia-manager/static/js/schedule/schedule_info.js:1-95`, `source-refs/sanmopia-manager/application/controllers/Reservation.php:6-77`, `source-refs/sanmopia-manager/application/models/Reservation_model.php:247-270`, `source-refs/sanmopia-manager/application/models/Reservation_model.php:351-411`, `source-refs/sanmopia-admin/static/js/manager/manager_pay_detail.js:235-260`, `source-refs/sanmopia-admin/application/controllers/Manager.php:1108-1129`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:2573-2624`	`care_delivery / CaregiverServiceBalanceShareProjection`, `CaregiverServiceBalanceAcknowledgementCommand`; `pricing_settlement / CaregiverPayoutStatement`	Backend-backed foundation	Caregiver schedule service-balance share is now represented by backend `CaregiverServiceBalanceSharePolicy` and required `serviceBalanceShare` contract fields on schedule items. The projection exposes exact integer share amount, role slot, confirmation state, command availability, disabled reason, statement reference, policy version, and source evidence so the portal cannot divide totals or infer main/sub payment status from source flags. Service-balance acknowledgement now has backend/application and public contract foundations that require assignment key, caregiver role, handoff order, payout statement reference, expected confirmation revision, expected payout statement revision, actor, reason, and idempotency key before state movement. 2026-07-07 source mining adds the manager portal raw `PUT /reservation/data` route: browser code posts `type=payment` or `type=sub_payment` plus `service_type`, the controller switches on that string, and the model stamps type-3 customer payment rows plus branch-manager payment flags. The sub-payment path updates `SUB_PAYMENT_STATUS_ID_FK` by reservation id only, so runtime writers must reject reservation-id-only acknowledgement and require assignment key/current roster revision. Backend `fbc60e4` now reads the frozen closeout event, caregiver receipt state, and payout instruction into the caregiver work-schedule share projection, applies a versioned deterministic equal-slot policy across multiple caregivers, and exposes reservation-scoped lookup. Positive-balance stage reservation `0b57b5f1-12c5-42f0-bcdf-7ab90e469a8b` reached `settled` with a frozen 25,000 KRW share. Backend `65a71ac` now invokes `CareTeamAssignmentProjectionWriter` after accepted assignment decisions and materializes `sanmopia_reservation_caregiver_assignments`: candidate profile and member-to-auth binding, grade snapshot, latest occurrence-ledger service-day count, booking dates, role, handoff order, and contract assignment key are persisted; replacement and clear decisions mark prior slots `replaced` or `removed`. Stage reservation `5dd549d3-6c2c-407c-b42a-fdcd7e769c6a` persisted its roster row before payout and reached `settled`. Remaining work: migrate runtime acknowledgement writers away from PHP/JS reservation-id-only mutation, make decision persistence plus roster projection atomic or durably replayable, repair failed projections, and backfill older accepted decisions.
P1	`source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4030-4050`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4058-4093`	`document_reporting / DailyReportArtifactSeriesSelection`	Backend-backed foundation	Customer daily-report bundle first/middle/last selection, stop-day-as-final behavior, assistant caregiver variants, caregiver question ids `1-1`/`2-1`/`3-1`, and one middle artifact per caregiver `CREATED_DT` are now represented by backend artifact-series selection policy plus contract schema. Members carry report audience, stage, source kind, service date, assignment key, caregiver role/id, source report evidence key, source evidence set, and deterministic member key so UI/document ids cannot decide the series. Remaining work: bind runtime artifact builder/render/storage workers and persisted report readers to the selection.
P1	`source-refs/sanmopia-admin/application/models/Reservation_model.php:10-48`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:160-276`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:644-923`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:4013-4045`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:4110-4137`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:4748-4764`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:4992-5014`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:5200-5208`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:5455-5496`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:5644-5658`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:408-470`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:938-963`, `source-refs/sanmopia-admin/application/models/Payment_model.php:3149-3179`, `source-refs/sanmopia-admin/application/models/Manager_model.php:2366-2372`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:167-376`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:629-780`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3507-3664`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3914-3940`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4284-4297`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4434-4450`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4511-4575`, `source-refs/sanmopia-admin/application/controllers/cli/ReservationDocument.php:19-132`, `source-refs/sanmopia-admin/application/controllers/cli/ReservationDocument.php:624-688`	`document_reporting / ServiceUseContractEvidenceSnapshot`, `ServiceUseContractRenderSource`, `ServiceUseContractPaymentEvidenceSnapshot`, `BranchStampAssetSnapshot`, `MotherSignatureAssetSnapshot`, `ChargeComponentRevisionSnapshot`, `ServiceOccurrenceSet`, `CareTeamDocumentProjection`, `ServiceUseContractRenderRequest`, `StoredPrintableDocumentArtifact`, `ContractTemplateEffectiveVersionDecision`, `DocumentCenterProjection`	Backend-backed foundation	Service-use contract render template selection, payment-deposited contract-date source, redacted identity birth evidence, service-period snapshot, latest caregiver-change evidence, charge component snapshot, and immutable signature/stamp asset references are now represented by backend domain/application contracts plus public TS/JSON schema. Charge components carry effect (`adds_to_customer_total`, `deducts_from_customer_total`, `informational`) so renderer/UI cannot recalculate totals from live reservation/payment/price rows. 2026-07-07 source mining: legacy render paths reload live reservation/payment/caregiver rows at render time, choose the service-use template by service-start year, write current/previous main caregiver from `RESERVATION_MANAGER_LOG_TB` or `MANAGER_TB`, and adjacent voucher/intake documents write provider count plus primary/sub caregiver names from `MANAGER_INFO`/`SUB_MANAGER`. Producer-side render source must freeze service period/type, mother name/contact/registered and service addresses, privacy-safe birth date derived from voucher resident-number fragments, branch legal/contact facts, branch stamp and mother signature asset references, payment deposited contract date, primary/current/previous caregiver display facts, assistant roster display facts by assignment key, manager personality text used by intake documents, service balance/custom balance, add-day facts, and price component revisions before render. Additional producer evidence must freeze source price-table outputs as `ChargeComponentRevisionSnapshot` and service/add-date rows as `ServiceOccurrenceSet`; renderers must not recompute voucher special/live-in surcharge, Saturday/holiday added-day counts, add-on multipliers, rental delivery hardcodes, or first SAT/HOLI display date from mutable rows. Admin download, customer/API, and scheduled-mail paths call the same numeric document-id renderer, upload transient XLSX files to the converter, overwrite temp filenames, and scheduled mail deletes attachments after send. Backend commit `5dd338b` queues service-use contract render requests from care-team assignment changes through `sanmopia_document_rendering` with assignment/source evidence and render idempotency. Backend commit `3cdc86a` consumes those queued requests through the document-render worker. Backend commit `e7972cc` records frozen `ServiceUseContractEvidenceSnapshotPayload` as `ServiceUseContractRenderSource` rows and adds readiness so incomplete rows retry instead of rendering. Backend commit `1ff144e` adds the producer-side fact-reader port/projector. Contract commit `d9faf9e` exposes render-source readiness/missing-fact contract. Backend commit `9f16fc1` adds Supabase fact reading for service-calendar plan, paid payment, care-team assignment decision, finalized charge snapshot, and finalized charge lines. Backend commit `c7ad654` projects render-source rows from care-team assignment invalidation and reads enabled document-definition active windows as the template decision. Backend commit `aa92fce` adds branch-stamp/mother-signature asset readiness facts and backend-owned document-center download readiness from stored artifacts. Backend commit `92aed4f` reads safe redacted resident identity evidence rows into `identity_evidence` without raw resident-number columns. Contract commit `7cb680d` exposes document-center projection and snapshot-revision-aware render request codes. Remaining work: redacted mother identity evidence producer, immutable branch stamp/mother signature asset snapshots, storage/access grants, and live E2E without live reservation/manager SQL at render.
P1	`source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:167-179`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:251-260`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:316-332`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4284-4297`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4434-4600`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:938-963`, `source-refs/sanmopia-admin/application/models/Branch_model.php:157-166`, `source-refs/sanmopia-admin/application/models/Branch_model.php:481-518`, `source-refs/sanmopia-admin/application/models/Branch_model.php:561-586`, `source-refs/sanmopia-admin/application/controllers/OfficeManagement.php:118-166`, `source-refs/sanmopia-admin/application/controllers/OfficeManagement.php:270-276`, `source-refs/sanmopia_web/static/js/reservation_payment.js:40-66`, `source-refs/sanmopia_web/application/controllers/api/Service.php:869-882`, `source-refs/sanmopia_web/application/models/Payment_model.php:12-42`, `source-refs/sanmopia_web/application/controllers/MyReservation.php:352-372`, `source-refs/sanmopia_web/application/views/mypage/reservation_document.php:118-139`, `source-refs/sanmopia_web/application/models/User_model.php:461-489`, `source-refs/sanmopia_web/application/controllers/api/ReservationDocument.php:21-55`, `source-refs/sanmopia_web/application/models/Reservation_model.php:2769-2820`, `source-refs/sanmopia-admin/application/controllers/SanmoInterface.php:37-51`, `source-refs/sanmopia-admin/application/controllers/cli/ReservationDocument.php:104-132`, `source-refs/sanmopia-admin/application/controllers/cli/ReservationDocument.php:200-227`, `source-refs/sanmopia-admin/application/controllers/cli/ReservationDocument.php:330-365`, `source-refs/sanmopia-admin/application/controllers/cli/ReservationDocument.php:666-688`	`document_reporting / RedactedMotherIdentityEvidenceSnapshot`, `BranchStampAssetSnapshot`, `MotherSignatureAssetSnapshot`, `StoredPrintableDocumentArtifact`, `PrintableDocumentAccessGrant`	Partial	Post-`c7ad654` producer gap evidence: backend now reads service-calendar, payment, care-team, charge, document-definition, and safe redacted identity evidence facts, but remaining facts still come from legacy live render behavior. Mother birth date is still reconstructed in legacy renderers from raw voucher resident-number fragments unless the modern producer writes `sanmopia_redacted_resident_identity_evidences`; branch stamp and mother signature are mutable file paths with overwrite/delete lifecycle and no version/checksum/grant; customer download uses a two-hour token plus live admin render and direct PDF byte stream; scheduled mail writes converter temp PDFs and deletes attachments after send. Next backend slices should produce the redacted identity evidence row, asset snapshots, stored artifact, and access grant facts before render.
P1	`source-refs/sanmopia_web/application/views/service/step3_voucher.php:70-90`, `source-refs/sanmopia_web/application/models/Reservation_model.php:488-510`, `source-refs/sanmopia_web/application/models/Reservation_model.php:2448-2458`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:5058-5066`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:938-963`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:251-260`; backend `42f7ed0` and `92aed4f` `service_use_contract_evidence_snapshot_projection.py`, `supabase_service_use_contract_evidence_snapshot_fact_reader.py`	`document_reporting / RedactedMotherIdentityEvidenceSnapshot`; `member_management / VoucherResidentIdentityEvidence`	Backend fact-reader foundation	Service-use contract mother birth date must not be produced by reopening raw voucher resident-number fragments during render. Source customer intake captures raw front/back resident-number values, stores them as `USER_NUMBER1`/`USER_NUMBER2`, admin creation writes the same raw columns, one clone path unsets those fields as sensitive, and the renderer still derives display birth date from the raw fragments. Backend now records `identity_readiness` from voucher recipient identity decision metadata, excludes raw resident-number and decision snapshot columns, and fills `identity_evidence` only when a safe `sanmopia_redacted_resident_identity_evidences` row supplies `birth_date`, `evidence_kind`, and `redaction_profile_key`. Remaining work: implement the producer that converts verified voucher identity into the redacted evidence row with display birth date, mask profile, source evidence key, source revision, and grant scope.
P1	`source-refs/sanmopia-admin/application/libraries/Uploadlib.php:47-90`, `source-refs/sanmopia-admin/application/libraries/Uploadlib.php:123-170`, `source-refs/sanmopia_web/application/libraries/Uploadlib.php:40-76`, `source-refs/sanmopia_web/application/libraries/Uploadlib.php:110-124`, `source-refs/sanmopia-admin/application/models/Branch_model.php:481-518`, `source-refs/sanmopia-admin/application/models/Branch_model.php:561-586`, `source-refs/sanmopia_web/application/models/Payment_model.php:12-42`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:183-207`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:316-332`	`document_reporting / BranchStampAssetSnapshot`, `MotherSignatureAssetSnapshot`; `branch_operations / BrandAssetLifecycle`	Partial	Legacy file handling records relative paths and original names only. Branch stamp and mother signature uploads overwrite mutable DB path columns and delete previous files; service-use contract rendering dereferences current files with `file_exists`. Implement asset producers with storage bucket/object key, object generation/version, sha256 checksum, byte size, media type, source row revision, actor/source command evidence, access grant reference, and readiness codes; renderer must consume asset snapshots only.
P1	`source-refs/sanmopia-admin/application/controllers/DataRoom.php:80-96`, `source-refs/sanmopia-admin/application/controllers/DataRoom.php:311-376`, `source-refs/sanmopia-admin/application/controllers/ajax/DataRoom.php:66-86`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3914-3940`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4284-4423`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4434-4600`, `source-refs/sanmopia_web/application/controllers/MyReservation.php:352-372`, `source-refs/sanmopia_web/application/views/mypage/reservation_document.php:118-139`, `source-refs/sanmopia_web/application/models/User_model.php:461-489`, `source-refs/sanmopia_web/application/controllers/api/ReservationDocument.php:21-55`, `source-refs/sanmopia_web/application/models/Reservation_model.php:2769-2820`, `source-refs/sanmopia-admin/application/controllers/SanmoInterface.php:37-51`, `source-refs/sanmopia-admin/application/controllers/cli/ReservationDocument.php:104-132`, `source-refs/sanmopia-admin/application/controllers/cli/ReservationDocument.php:200-227`, `source-refs/sanmopia-admin/application/controllers/cli/ReservationDocument.php:330-365`, `source-refs/sanmopia-admin/application/controllers/cli/ReservationDocument.php:666-688`	`document_reporting / StoredPrintableDocumentArtifact`, `PrintableDocumentAccessGrant`, `ServiceUseContractRenderSourceOnlyArtifactBuilder`	Partial	Admin data-room and customer document flows still pass numeric document ids into live renderers. `makePdfData()` and `makePdfDataToSendMail()` reload mutable reservation/service/rental rows, write temp XLSX/PDF files named from current mother/reservation data, call the converter, and return direct bytes or temp paths; scheduled mail deletes attachments after send; customer access is a two-hour token over `USER_TOKEN_TB`. Implement a service-use-contract render-source-only artifact builder, persist `StoredPrintableDocumentArtifact` with checksum/storage-version/render-source revision, issue `PrintableDocumentAccessGrant` per customer/admin/mail surface, and guard or reroute legacy live-render path for document id `1`.
P1	`source-refs/sanmopia-admin/application/controllers/DataRoom.php:80-96`, `source-refs/sanmopia-admin/application/controllers/ajax/DataRoom.php:66-86`, `source-refs/sanmopia_web/application/views/mypage/reservation_document.php:118-139`, `source-refs/sanmopia_web/application/controllers/api/ReservationDocument.php:21-55`; backend `aa92fce` `application/document_reporting/features/document_center/project_document_center.py`; backend `695943a` `interfaces/document_center_http.py`; contract `7cb680d` `packages/ts-client/src/types/document-reporting.ts:806-864`	`document_reporting / DocumentCenterProjection`, `DocumentCenterCatalogItem`, `DocumentCenterDownloadHandoffDescriptor`, `DocumentCenterBundleDownload`; `frontend / DocumentCenterStore`	Backend API bound	Backend now projects document-center catalog eligibility, latest stored artifact metadata, per-document handoff descriptors, bundle included/missing definition keys, and bundle availability. FastAPI exposes the projection through authenticated `GET /document-center-projections/{reservationBookingId}` with camelCase aliases. Contract exposes the projection fields. Frontend must consume this through a Nanostores-backed document-center store and render actions from backend handoff descriptors; browser code must not compose numeric document ids, token query strings, render request codes, bundle members, missing-artifact state, or service-kind eligibility. Remaining work: signed-storage handoff implementation, frontend store/view-model integration, and legacy live-render guard/reroute for service-use contract document id `1`.
P1	`source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:183-225`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:316-332`, `source-refs/sanmopia-admin/application/models/Branch_model.php:157-166`, `source-refs/sanmopia-admin/application/models/Branch_model.php:481-504`, `source-refs/sanmopia-admin/application/models/Branch_model.php:561-575`, `source-refs/sanmopia-admin/application/controllers/OfficeManagement.php:118-166`, `source-refs/sanmopia-admin/application/controllers/OfficeManagement.php:270-276`, `source-refs/sanmopia_web/static/js/reservation_payment.js:40-66`, `source-refs/sanmopia_web/application/controllers/api/Service.php:869-882`, `source-refs/sanmopia_web/application/models/Payment_model.php:12-42`	`document_reporting / ServiceUseContractAssetSlotSnapshot`, `BranchStampAssetSnapshot`, `MotherSignatureAssetSnapshot`, `ServiceUseContractAssetReferenceSnapshot`; `branch_operations / BrandAssetLifecycle`	Backend-backed foundation	Service-use contract places current branch stamp and mother signature into year-dependent slots `P69`/`P66` and `J69`/`J66`. Source reads `BRANCH_TB.STAMP_IMG_URL` again during render, converts that mutable file to JPEG, and reads `RESERVATION_TB.SIGN_IMG_URL` after the customer payment-request flow overwrites the signature image and deletes the previous file. Branch stamp can also be uploaded/deleted through office-management actions without artifact versioning. Backend now models `ServiceUseContractAssetSlotDefinition`, `ServiceUseContractAssetSlotSnapshot`, immutable asset version/checksum/grant data, slot readiness, and public contract/schema so renderers do not dereference current mutable branch stamp or mother signature paths. Remaining producer work: persist `BranchStampAssetSnapshot` and `MotherSignatureAssetSnapshot` into `ServiceUseContractRenderSource` with storage object version/checksum/source revision/readiness, connect branch/customer media lifecycle revisions from `BrandAssetLifecycle`, and issue storage/access grants.
P1	`source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:629-636`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:644-660`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:667-699`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:711-725`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:731-779`	`document_reporting / DownPaymentBreakdownArtifactLineSnapshot`; `pricing_settlement / ChargeComponentSnapshot`	Backend-backed foundation	Down-payment artifact line projection now consumes frozen charge components and maps them to explicit slot projections, so document rendering cannot recalculate voucher surcharge, Saturday/holiday add-on, rental, pump, delivery, checkbox, quantity, or amount formulas. Public contract exposes component kind, quantity basis, unit/total amount, source price key, pricing policy version, calculation reason, included-in-total flag, display label, slot kind/key/value, and source evidence. Remaining work: bind pricing settlement quote/catalog builders and Supabase persistence to produce the frozen components.
P1	`source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:629-636`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:719-725`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:5985-6012`	`pricing_settlement / DownPaymentVoucherSurchargeComponentSnapshot`; `document_reporting / DownPaymentArtifactSlotProjection`	Backend-backed foundation	Voucher `입주/스페셜` surcharge can now be represented as `voucher_surcharge` frozen component with source price key, pricing policy version, calculation reason, and slots such as `AA10`/`AC12`. Remaining work: bind voucher add-on price reader and price-version/service-detail basis to persisted pricing snapshot.
P1	`source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:647-660`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:731-779`, `source-refs/sanmopia-admin/application/models/Service_model.php:238-254`, `source-refs/sanmopia-admin/application/models/Payment_model.php:4196-4219`	`pricing_settlement / AdditionalServiceChargeComponent`; `document_reporting / DownPaymentAdditionalServiceLineSlotProjection`	Backend-backed foundation	Added-day/add-on document lines now have frozen quantity basis (`effective_service_day`, `added_service_day`, `item_quantity`, or `source_component_total`) plus slot projections, preventing duplicated renderer formulas. Remaining work: bind actual additional-service pricing policy and mismatch repair between quote path and document path.
P1	`source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:667-699`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:748-770`, `source-refs/sanmopia-admin/application/config/constants.php:99`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:21`	`pricing_settlement / RentalEquipmentChargeComponent`; `document_reporting / DownPaymentRentalEquipmentLineSlotProjection`	Backend-backed foundation	Rental and delivery document lines now represent rental item charge, delivery fee, source price key, policy version, catalog/display label, checkbox slot, and included-in-total flag without hardcoded renderer fees. Remaining work: bind rental catalog and delivery max-once decision from pricing settlement.
P1	`source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3950-3953`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4307-4309`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4459-4461`, `source-refs/sanmopia-admin/application/controllers/cli/ReservationDocument.php:72-95`, `source-refs/sanmopia-admin/application/controllers/cli/ReservationDocument.php:182-192`, `source-refs/sanmopia-admin/application/controllers/cli/ReservationDocument.php:648-653`	`document_reporting / DownPaymentArtifactEligibilityProfile`	Backend-backed foundation	Down-payment artifact eligibility is now a backend profile/decision with actor channel (`admin_bulk_download`, `customer_pdf`, `start_mail_attachment`, `manual_send`), service kind, start-mail payment cutover, manual-send allowance, reason code, template version, and source evidence. Remaining work: persist profile revisions, bind catalog/document-delivery routes, and remove numeric id `4` bundle arrays from callers.
P1	`source-refs/sanmopia-admin/application/config/constants.php:228-231`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3959-3999`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:1046-1051`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:2616-2690`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:334-376`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:2829-2853`	`document_reporting / CaregiverServiceRecordRoleScopedArtifactSeries`, `CaregiverServiceRecordChunkWindowSnapshot`, `CaregiverServiceRecordSourceReaderConsistency`	Partially represented	Service-record export uses doc id `6` for primary `MANAGER_SERVICE_TB`, doc id `20` for assistant `MANAGER_SUB_SERVICE_TB`, emits artifact filenames with offset but no role marker, chunks exactly 10 rows per artifact, stops when `count <= offset`, and uses template 10 repeated column/signature slots. Source render ordering joins signatures by `SERVICE_DT`, while reset reader uses `CREATED_DT` without the same signature join. Backend bundle must own role-qualified artifact keys, source table/reader, assignment key, ordered record ids, chunk size/start offset/index, total source count, no-empty-overflow rule, frozen caregiver/mother signature asset refs, and missing-signature readiness reasons.
P1	`source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:815-837`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:844-857`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3955-3957`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4311-4313`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4463-4465`, `source-refs/sanmopia-admin/application/models/Payment_model.php:191-211`, `source-refs/sanmopia_web/application/models/Payment_model.php:12-40`, `source-refs/sanmopia-admin/application/controllers/SanmoInterface.php:37-51`	`document_reporting / PrivacyConsentFactSnapshot`, `PrivacyConsentSignatureAssetSnapshot`, `PrivacyConsentArtifactEvidenceSnapshot`	Backend-backed foundation	Privacy consent sheet legacy behavior now has backend/domain and public contract foundation: consent fact snapshot requires signer/member identity, capture source, timezone-aware consent timestamp, explicit accepted consent categories, source evidence, and payment evidence only as migration evidence for signed-source artifacts. Signature snapshot requires immutable storage object version key, checksum, signer match, grant policy, and source evidence. Artifact evidence returns channel-neutral readiness (`ready`, `missing_consent_category`, `missing_signature_asset`, `incomplete_signature_asset`), so payment `DEPOSITED_DT`, auto-checked boxes, current `SIGN_IMG_URL`, deleted previous files, or missing signature cannot silently become render authority. Remaining work: persist consent/signature snapshots in Supabase, bind customer upload migration, render worker, and access-grant workflow.
P1	`source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:1083-1132`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:1212-1219`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:5078-5128`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:5136-5144`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:5211-5225`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:5230-5240`, `source-refs/sanmopia_web/application/models/Constdata_model.php:165-216`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:5636-5663`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:5805-5820`	`document_reporting / VoucherReceiptBenefitPeriodSnapshot`, `pricing_settlement / VoucherPlanCatalogRevisionSnapshot`	Backend-backed foundation	Voucher receipt and catalog source behavior now has backend/domain, application contract, public TS, and JSON Schema foundation. `VoucherPlanCatalogRevisionSnapshot` freezes consume-type id/value/parts, positional service-day classification enum, price version, service detail, baby type, delivery count, price lines, government/customer/caregiver amounts, live-in conversion, add-option revision, and price-row evidence. `VoucherConsumeTypeRemapDecision` blocks price-version remap when `SERVICE_DAY_LIST` signature changes and carries optional `compatibilityRuleKey` for source catalog-transition exceptions instead of exposing numeric id formulas. `VoucherReceiptBenefitPeriodSnapshot` freezes branch, benefit period, consume-type parts, service-day classification, catalog/price-line keys, and receipt amounts so template/UI cannot split strings or infer list-index meaning. Backend `2c744fb` persists and publishes immutable normalized voucher-plan revisions, validates the exact ordered option/price-line/entry-code bijection against a published zero-issue price batch, restores secondary caregiver net pay during import, and projects the ordered non-monetary service-day catalog through named orchestration. Backend `c1937ed` adds completed source revisions/slices, explicit service-detail/baby-type/delivery-count/benefit-band/day axis binding without `consume_type_` prefix inference, atomic full-population publication, population-linked revision reads, and exact committed selection without caller-owned revision/batch/version keys or `latest` fallback. Backend `b44fd49` binds the exact selector to the reservation bridge using canonical axes/date only and rejects decision drift before revision read. Backend `7a9d26e` adds the active-session HQ/SpiceDB approval caller, DB-owned time and canonical manifest, approved-only RPCs, legacy-row quarantine, and immutable linkage guards. Remaining work: business selection, approval, and invocation of one exact source/version, canonical draft-axis resolution, draft prepare trigger and exact-26 snapshot refresh, receipt snapshot persistence, receipt renderer/settlement readers, and historical voucher receipt backfill.
P1	`source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:1134-1204`; `source-refs/sanmopia-admin/application/models/Branch_model.php:481-513`; `source-refs/sanmopia-admin/application/models/Manager_model.php:1559-1593`, `source-refs/sanmopia-admin/application/models/Manager_model.php:1667-1684`	`document_reporting / PrintableSignatureAssetSnapshot`	Backend-backed foundation	Source documents dereference mutable stamp/signature file paths at render and profile updates delete previous media. Backend now adds shared `PrintableSignatureAssetSnapshot` and replacement planning with owner kind, role, immutable storage object version key, checksum, lifecycle state, retention policy, superseded asset pointer, and public contract/schema. Old branch/caregiver media can be marked superseded-retained instead of deleted, so historical contracts/receipts do not drift. Remaining work: persist asset snapshots in Supabase/R2, bind branch/caregiver/customer upload flows, and route render workers through snapshot references only.
P1	`source-refs/sanmopia-admin/application/controllers/ajax/Reservation.php:144-158`	`pricing_settlement / PaymentChangeAdjustmentAmountBreakdown`, `MotherVisibleChargeSnapshot`	Backend-backed foundation	Payment-change tables must not recompute coupon totals inside an ajax list. Backend now models approval-time `PaymentChangeAdjustmentAmountBreakdownSnapshot`, `MotherVisibleChargeSnapshot`, coupon allocation evidence, discount source, queryable Supabase snapshot columns, operator-board projection fields, and public TS/JSON schema contract so UI cannot recalculate the displayed amount from mutable coupon rows. 2026-07-06 follow-up: the backend HTTP/API request boundary now requires nested `requestedAmountAuthority`, converts that frozen authority into the application command, and rejects the legacy scalar `customerDeltaKrw`/`couponAdjustmentKrw`/`pureCustomerAmountKrw` request shape before handler execution. 2026-07-06 regional-benefit follow-up: requested amount authority now includes `RegionalBenefitChargeImpactAcknowledgement`; Supabase stores the acknowledged finalized charge snapshot id plus frozen impact event ids, and the handler rejects stale or missing acknowledgements before accepting payment-change amount authority. Remaining work: bind every runtime approval reader to create snapshots for payment-change paths, backfill legacy rows from source evidence, and update external clients to send authority snapshots only.
P1	`source-refs/sanmopia-admin/application/controllers/Reservation.php:1739-1758`	`reservation_operations / ServiceAreaCalendarProfile`, `service_calendar / ServicePeriodPlan`	Backend-backed foundation	Source locality day additions now resolve through backend-owned service-calendar policy profile rows with `service_area_profile_key`, optional matched service-area rule evidence, address scope, branch profile, effective dates, and policy fingerprint. `SupabaseServiceCalendarPolicyProfileReader` selects exact service-area/branch/rule snapshots before global fallback, and generated contracts expose frozen policy-profile evidence on service-calendar plan snapshots so UI cannot add days from source locality labels. Remaining work: bind booking/admin mutation runtime to branch service-area decisions, backfill historical profile rows, expose operator profile management, and verify pricing/matching/refund/settlement consumers read the frozen plan evidence.
P1	`source-refs/sanmopia-admin/application/controllers/Wintherace.php:109-130`, `:237-323`; `source-refs/sanmopia-admin/application/models/Win_the_race_model.php:8-150`, `:150-310`; `source-refs/sanmopia-admin/application/views/win_the_race/branch.php:188-228`; `source-refs/sanmopia-admin/static/js/win_the_race/branch.js:73-115`, `:240-323`	`business_reporting / PerformanceRecognitionProgram`, `RecognitionScorecardSnapshot`, `RecognitionLeaderboardSnapshot`; `branch_operations / BranchRecognitionEligibilityProfile`	Partial	Backend domain foundation now models recognition program metrics with explicit date basis, closeout as `RecognitionProgramCloseoutSnapshot` instead of `file_exists`, branch eligibility as `BranchRecognitionEligibilityProfile` with standard/new-branch/ineligible decisions, public TS/JSON contracts for `RecognitionScorecardSnapshot` plus `RecognitionLeaderboardSnapshot`, and Pydantic application-boundary payloads for scorecard/leaderboard snapshots. Branch scorecard contribution lines freeze YoY/count/sales/manual adjustment points and total-score equality, so view/JS cannot recompute WinTheRace totals or tied ranks. Source numeric branch ids remain evidence only; target branch profile keys own identity. Remaining work: Supabase persistence, branch/HQ approval workflow, generated artifact state, manager scorecard/recommendation scoring, sales aggregation readers, command/query handlers, and UI binding.

Open Gap Register

These rows keep source-backed work visible while backend workers migrate slices. Requires source-dig means existing docs identify the gap, but exact source parity still needs deeper source verification before marking Migrated.

Gap area	Current status	Checklist anchors	Required migration gate
Reservation lifecycle and collaboration	Partial	`reservation_operations / reservation_collaboration`, `service_calendar`, `pre_reservation_conversion`, `customer_reservation_intake_draft`, `customer_reservation_intent`	Every reservation create/change/convert/cancel/extend/stop/offline path writes backend commands, expected revisions, durable state transitions, service-calendar impact facts, and actor-stage projections.
Pricing, quote, subsidies, and price catalog	Partial	`pricing_settlement / public_fee_guide_catalog`, `price_catalog_import_execution_audit`, `regional_benefit_policy`, `reservation_price_version_adjustment`	Price catalog, regional support/subsidy, voucher/general version policy, add-day/rental/coupon facts, and charge snapshots are effective-dated backend facts. UI calculators become diagnostics only.
Payment and billing through Kill Bill	Partial	`customer_payment_instruction`, `payment_change_adjustment`, `PaymentProductPlan`, `ReservationPaymentWorkflow`, Kill Bill admin operations	Backend freezes product plan, method, route, fee, amount, provider context, communication request, idempotency, and workflow state before provider handoff. No UI payment-purpose inference. Backend follow-up on 2026-07-08 moved payment-change operator board access to HQ settlement `review_hq_settlement`, row visibility to `reservation_booking#view`, and payment repair/fact-edit commands to booking-scoped `finalize_charge` / `close_reservation_finance` checks instead of Supabase role metadata. 2026-07-08 RBAC hardening now resolves `OperatorPaymentFactEditCommand` actor kind through SpiceDB `reservation_booking#review_hq_settlement` or booking-branch `manage`, and reads branch scope from backend booking state instead of Supabase `app_metadata.branch_profile_id`.
Refund and partial refund	Partial	`payment_refund`, `ReservationCancellationRefundPolicy`, `PaymentRefundIntent`, `PaymentAdjustmentCatalog`	Refund quotes, coupon/benefit restore, zero-gateway refunds, partial provider cancel events, operator overrides, receipt artifacts, and settlement reversals are ledger-backed.
Settlement: external counterparty, branch, HQ, inter-office	Partial	`settlement_statement`, `settlement_data_room`, `settlement_collection_export_repository`, `InterOfficeSettlement`, `SettlementDataRoomCollection`, `ReservationExternalSettlementCounterpartyStatus`	Branch/HQ/external-counterparty/inter-office statements, row acknowledgements, manual rows, export datasets, repair history, signed grants, and workflow states stay separate. Branch settlement board source status codes are now mapped by `branch_settlement_status_acl.py`, not domain enum methods. 2026-07-09 naming hardening moved board transition import repair to `settlement_board_transition_provenance`, `ImportedSettlementBoardTransitionRow`, and `source_branch_marker` so old-source vocabulary stays out of domain/application contracts. Reservation-scoped external counterparty source status codes are now mapped by `external_settlement_counterparty_status_acl.py`, not domain helpers. Source-specific API routes, Supabase table names, and external-recipient protocol require source-dig plus forward compatibility migration before final contract naming.
Caregiver matching and payroll	Partial	`caregiver_matching`, `assignment_decision_evidence`, `caregiver_compensation`, `caregiver_payout_statement`, `CaregiverPerformanceScorecard`	Candidate snapshots, policy version, optimizer input, assignment decision, grade snapshot, ordered assistant roles, payout slot, tax election, and receipt state are backend facts. Backend follow-up on 2026-07-08 moved care-team current roster, assignment history, and compensation source reads behind SpiceDB `reservation_booking#view` checks before any caller-scoped Supabase RLS reader/repository is opened.
Document generation, printing, and grants	Partial	`printable_document`, `printable_template_version_manifest`, `ReservationDocumentTemplate`, `VoucherEndNoticeReadiness`, `CustomerDocumentAvailabilityProjection`	Catalog, template version, A4/PDF/ZIP artifacts, start/end delivery batches, signed/revoked grants, retry ledger, and access history are persisted backend state.
RBAC and SpiceDB authorization	Partial	`ActorStageCapabilityProjection`, `OperatorIdentitySession`, `BranchRelationshipGrant`, `Identity and RBAC end-to-end`	Supabase Auth supplies actor identity only. Supabase `app_metadata`, profile `member_role`, and RLS predicates are non-authoritative hints/safety rails, not Sanmopia app RBAC. SpiceDB relationship checks own branch/HQ/reservation/caregiver/settlement capability decisions; OPA owns policy-context gates, field visibility, disabled reason, and audit context. Backend follow-up on 2026-07-08 centralizes HQ-scoped authority object IDs in `SanmopiaSpiceDBAuthorityId` and extends the SpiceDB relationship outbox so branch-to-HQ sync also queues every `hq_settlement#headquarters_branch` authority tuple. Same RBAC pass moves caregiver grade recalculation history to `HQ_SETTLEMENT:caregiver_grade_recalculation_history#review_hq_settlement`, derives workflow-status reservation capability actor kind from SpiceDB/resource ownership instead of JWT roles, resolves family-account member identity from backend-owned member profiles instead of `app_metadata.member_id`, removes the caregiver schedule JWT-role gate, deletes the unused settlement actor metadata helper, and revokes direct authenticated Data API reads from caregiver grade history tables so backend service-role reads happen only after SpiceDB authorization. Follow-up export pass moves reservation-history dataset/artifact reads behind SpiceDB branch/booking checks and removes direct authenticated Data API policies from reservation-history export tables. Service-calendar holiday audit writes/previews now rely on backend SpiceDB `service_calendar#manage` and `branch#manage` checks before service-role persistence, with direct authenticated Data API policies revoked/dropped from the audit tables. Payment fact edit actor resolution now ignores forged Supabase branch metadata; HQ operators require booking `review_hq_settlement`, branch operators require backend booking branch scope plus SpiceDB branch `manage`. Open RBAC audit item: platform-level active-member/session helpers still expose app-metadata role/privacy accessors until member privacy/session projection fully owns them.
Workflow and state management	Partial	`WorkflowStatusProjection`, `ReservationBookingWorkflow`, `ReservationPaymentWorkflow`, `ReservationFinancialLifecycleWorkflow`, `MemberPrivacyLifecycleWorkflow`	Restate owns durable workflow execution; Supabase owns service-role ledgers/read/RLS; portals poll filtered backend projections and never call workflow internals or infer state from raw rows.
Approval and settlement workflow authorization	Partial	`HeadOfficeManagerOperations`, `BranchOwnerOperations`, `SettlementStatementCommandHandler`, `BranchSettlementReconciliationExportWorkflow`	HeadOfficeManager approval and BranchOwner acknowledgement commands must share Supabase Auth identity, SpiceDB relationship checks, expected revision, idempotency fingerprint, append-only transition audit, and Restate repair/export workflows. Backend follow-up on 2026-07-08 split settlement statement, settlement data-room, and inter-office settlement actor-kind authorization from Supabase metadata: branch preparation/data-room commands require `prepare_branch_settlement`, HQ review/private memo/data-room and inter-office opening require `review_hq_settlement`, data-room workflow progress requires the workflow authority check, inter-office opening also checks both customer/service branch `settle` scopes, and forged/stale app metadata cannot promote a branch actor to HQ reviewer or workflow actor. Same RBAC pass now removes metadata-only workflow-status fallbacks and KillBill admin-operation role bypasses: workflow projections require same-user ownership or concrete SpiceDB resource ids, and KillBill admin operations require booking `close_reservation_finance` or HQ settlement `close`. Follow-up workspace pass now derives settlement data-room workspace actors from SpiceDB permission paths (`branch#prepare_branch_settlement`, `branch#review_hq_settlement`, HQ/workflow settlement authorities) instead of Supabase role metadata, and the relationship outbox now seeds those HQ authority resources from branch-to-HQ sync. Remaining audit: source-dig hidden authorization helpers and profile/audit enrichment paths still need removal or explicit non-authority documentation.
Audit and conflict resolution	Partial	`ReservationCollaborationWorkspace`, `ReservationCollaborationConflictLog`, `SettlementTransitionAudit`, `WorkflowStatusProjection`	Stale writes return conflict diffs, not silent overwrites. Reservation, payment, settlement, branch-profile, and document repair commands must persist actor, reason, expected revision, decision winner, and repair linkage before portals refresh.
OTel, load, and queue readiness	Partial	`observability-backpressure`, `SupabaseQueueContract`, `SupabaseQueueWorker`, `WorkflowStatusProjection`	Queue depth, oldest age, retry, dead-letter, in-flight worker, workflow-blocked, payment-provider latency, and settlement-export latency signals must be emitted through OpenTelemetry with trace context and idempotency keys.

2026-07-06 Source-Dig Delta

Priority	Status	Modern ubiquitous name	Source evidence	Migration note
P0	Partial	`RegionalBenefitEligibilityDecision`	`source-refs/sanmopia-admin/application/views/reservation_status/reservation_add.php:254-303`, `source-refs/sanmopia-admin/static/js/reservation_status/reservation_add.js:874-948`, `:1231-1253`, `:1519-1539`, `source-refs/sanmopia_web/application/views/service/step3_voucher.php:142-185`, `source-refs/sanmopia_web/static/js/step3.js:886-942`, `source-refs/sanmopia_web/static/js/step3_voucher.js:80-137`, `:190-195`, `:345-379`	Source eligibility is two separate local benefits. Wanju: voucher service only, service address level 2 starts as `완주군`, operator/customer must choose apply yes/no, then detail option `일반` or `50% 이하자`; selected option posts add-option id/name/price and service-day bonus. Yeongdeungpo: voucher service plus service address `서울`/`영등포구`, then explicit health-center discount apply flag; source comment marks some UI removed but model/payment paths still consume `YEONGDEUNGPO_FL`. 2026-07-06 backend follow-up: `RegionalBenefitEligibilityDecision` is now a public domain name, applied lines preserve `source_evidence_key`, Supabase regional-benefit rules load/persist `source_evidence_key`, and booking HTTP/API plus TS/JSON contracts carry nullable `sourceEvidenceKey` on accepted regional benefit lines. Remaining work: reservation entrypoints must resolve the decision from catalog/address/profile data before workflow start, add explicit decision ids and option/grant state, and ensure UI/admin forms render decisions without branching on raw `sigungu`, `wanju_fl`, `wanju_option`, or Korean region labels.
P0	Partial	`RegionalBenefitChargeImpactSnapshot`	`source-refs/sanmopia-admin/application/models/Reservation_model.php:714-816`, `:1498-1534`, `:4103-4180`, `:4864-5038`, `:5233`, `:5628-5642`; `source-refs/sanmopia-admin/application/models/Payment_model.php:436-437`, `:3760-3764`; `source-refs/sanmopia_web/application/models/Reservation_model.php:1181-1195`, `:1267-1274`, `:2523-2553`, `:2680-2692`, `:2839-2845`; `source-refs/sanmopia_web/application/controllers/api/Service.php:346-349`	Source charge impact spans quote, payment, service period, and persistence. Yeongdeungpo subtracts `DISCOUNT_YEONGDEUNGPO_PRICE_LATEST` from displayed discount and own-price/customer-fee math only when voucher + address level 1 `서울` + level 2 `영등포구` + flag `YEONGDEUNGPO_FL == 1`; admin payment also requires branch id 20 in some settlement/payment summaries. Wanju inserts voucher add-option ids 24/25 or selected option id, adds one option row, adds 5 service days/end-date days, and changes customer-visible add-price/service-period calculations. 2026-07-06 backend follow-up: domain now has `RegionalBenefitChargeImpactSnapshot` with `eligibility_decision_id`, `benefit_code`, `profile_key`, stable `source_option_key`, `source_required_flag_key`, discount/own-price/service-day/end-date deltas, settlement participation, amount source key, catalog/price version, address proof, actor/source surface, and frozen line event id. `RegionalBenefitRule` and Supabase policy rows carry `policy_version_label`, `source_option_key`, `own_price_adjustment_krw`, and `service_end_date_delta_days`; `FinalizeReservationChargeWithRegionalBenefitHandler` freezes impact snapshots into `FinalizedReservationChargeSnapshot`, `sanmopia_finalized_charge_snapshots.regional_benefit_charge_impact_snapshots`, and booking RPC payloads. Refund requotes now have `RegionalBenefitRefundImpactReference`, `SupabaseRegionalBenefitRefundImpactReader`, HTTP/API acknowledgement fields, and composition-root wiring, so cancellation refunds cannot silently requote against stale regional-benefit frozen lines. Approved-payment charge finalization now validates regional benefit summary columns against the same frozen impact rows before opening or advancing the financial lifecycle. Payment-change amount authority now requires `RegionalBenefitChargeImpactAcknowledgement` against the finalized charge snapshot and frozen impact event ids before accepting a customer-visible adjustment amount. Remaining work: payment conversion, service calendar, branch settlement, and HQ settlement consumers must read this frozen impact array instead of re-evaluating locality/option flags.
P0	Partial	`BranchCoverageAddressFallbackRule`	`source-refs/sanmopia_web/application/models/Branch_model.php:45-126`	Source serviceability splits composite `address2` values, checks exact/parent/city-wide/fallback keys, and vetoes possible/consultation matches when an impossible-area row also matches. Backend now promotes ordered coverage lookup key generation into shared kernel so `AddressAdministrativeProfile`, managed service-area lookup, and `BranchServiceAreaPolicy.resolve_active_policy` use the same exact, parent, level-1, and composite-level-2 fallback order. `BranchServiceAreaPolicyDecision` now carries `lookup_address_key_values`, `matched_lookup_address_key`, `matched_lookup_address_depth`, and `vetoed_serviceable_rule`; HTTP/TS/JSON contracts expose the same evidence, and Supabase stage schema persists `coverage_lookup_address_keys`, `resolved_lookup_address_key`, `resolved_lookup_address_depth`, and `vetoed_serviceable_policy_rule_reference` on `sanmopia_branch_service_area_address_evidence`. Remaining migration: bind first-period, second-period, extension, and continuation reservation workflows to this frozen decision before branch ownership, pricing, matching, and transfer audit run.
P0	Partial	`OperatorPaymentFactEditCommand`	`source-refs/sanmopia-admin/application/views/reservation_status/reservation_detail.php:1217-1272`, `source-refs/sanmopia-admin/static/js/reservation_status/reservation_add.js:1350-1379`, `source-refs/sanmopia-admin/application/controllers/Reservation.php:676-687`, `source-refs/sanmopia-admin/application/controllers/Reservation.php:849-859`, `source-refs/sanmopia-admin/application/controllers/Reservation.php:1538-1616`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:1566-1678`	Admin UI exposes deposit-date fields by service type/payment version, hardcodes offline reservation status `19` on add, posts service-balance deposit date only when browser status text is `완료`, and controller writes reservation deposit, balance deposit, and service-balance deposit rows from those raw dates. Model code treats date presence as paid/unpaid, blocks only refunded rows, and recalculates payment amount from current coupon, pre-reservation, in-home surcharge, Yeongdeungpo discount, and service-balance policy while overwriting `PRICE`, `DEPOSITED_DT`, and `PAYMENT_STATUS_LIST_ID_FK`. 2026-07-06 backend follow-up: commit `8786359` adds `pricing_settlement/features/payment/operator_payment_fact_edit` with `OperatorPaymentFactEditCommand`, `OperatorPaymentDateCorrectionPolicy`, payment purpose, explicit paid/unpaid intent, recorded deposit date, expected payment revision, actor capability evidence, reason, idempotency key, immutable amount snapshot, correction audit, shared audit fingerprint helper, and projection invalidation keys. Commit `5a2ac5c` adds the application handler/store port, Supabase payment-fact read adapter, idempotent correction lookup, RPC-backed persistence, `sanmopia_operator_payment_fact_corrections`, payment-record revision/snapshot columns, service-balance closeout RPC lint fix, and restrict FK retention guard. Commit `ff4e996` adds protected HTTP/API binding, Supabase-auth actor derivation, SpiceDB-backed capability evidence, main app handler wiring, and correction response facts for audit/projection refresh. Commit `4f7b672` blocks legacy-style existing payment fact overwrite through the receipt path and points callers to `OperatorPaymentFactEditCommand`. Commit `9de2d68` backfills historical payment-row amount snapshots and makes new receipt/pre-registration rows write deterministic payment fact amount snapshot keys. Commit `49245dc` projects payment fact amount snapshot keys onto payment-change operator board rows and invalidates settlement board read models for manual payment fact edits. Commit `183f8f4` blocks reservation collaboration payment-date broad-save, exposes `payment_fact.operator_edit_targets` with payment fact id/revision/amount snapshot evidence for reservation detail, and removes unsafe security-definer use from payment fact correction RPCs. 2026-07-07 debt follow-up: `PaymentCorrectionAmountChange` now gives payment-date correction and payment-change amount-correction audit one shared previous/corrected amount vocabulary and signed delta instead of duplicate non-negative amount guards. 2026-07-08 RBAC follow-up: `ReservationPaymentRecordAuthorizationService.authorize_operator_payment_fact_edit_actor()` derives HQ/branch actor kind from SpiceDB permission paths and reads booking branch scope through `SupabaseReservationPaymentBookingScopeReader`; Supabase `app_metadata.branch_profile_id` is ignored. 2026-07-13 contract/frontend boundary follow-up adds public OpenAPI and TS request/response contracts for `/reservation-payment-facts/{paymentFactId}/operator-corrections`, validates explicit intent, expected revision, frozen amount snapshot, paid-date consistency, audit response, and projection invalidations, and adds the authenticated frontend client adapter. Remaining migration: reservation-detail projection must render command targets and bind the admin controls to this client. Browser forms must not infer payment status, amount, or lifecycle transition from date fields or display status text.
P0	Partial	`PaymentProviderCloseoutCompensationSaga`	`source-refs/sanmopia_web/application/controllers/api/Payment.php:13-58`, `:150-218`, `:272-303`, `:388-413`, `:553-591`, `:720-762`; `source-refs/sanmopia_web/application/models/Payment_model.php:383-435`, `:856-900`; `source-refs/sanmopia_web/application/libraries/Kcppayment.php:418-475`	KCP-era closeout has provider action followed by local reservation/payment/coupon/payment-change writes. The approval-key route reads `good_mny` and `Ret_URL` from browser GET despite the inline warning that amount/return URL should come from server session; reservation deposit, gift-coupon payment, customer-share balance, pre-reservation deposit, and payment-change/card-replacement all call the provider first, then call local model writes, then attempt immediate full KCP cancel (`STSC`) on local DB/transaction failure. Inline compensation results are not durable: each controller path calls `$kcppayment->refund()` and immediately returns the original local error, while `Kcppayment::refund()` always returns `status => false` even after a provider refund request. Payment-change init accepts posted `price`, deletes unpaid drafts, and later stores provider context plus `DEPOSIT_DT`. Modern Kill Bill replacement must start from a backend `CustomerPaymentInstruction`/payment-change adjustment id with frozen amount, purpose, payer, return route, provider method, settlement participation, expected revision, idempotency key, and communication plan; provider success and local persistence failure must create an auditable compensation refund intent instead of an inline best-effort KCP cancel. 2026-07-08 status proof: Kill Bill webhook acceptance and processing now exist at `backend-repo/src/sanmopia_modernization/interfaces/killbill_payment_event_http.py:65-96` and `backend-repo/src/sanmopia_modernization/application/pricing_settlement/features/payment/killbill_payment_event.py:356-428`, including paid webhook amount mismatch failure before workflow start. Remaining proof: provider-attempt persistence for every payment purpose, compensation refund retry/workflow when local persistence or workflow start fails after provider success, partial/full refund capability mapping, and tests proving browser amount/return-url tampering, payment-change stale draft supersession, provider success plus DB/workflow failure, and provider refund failure do not leave paid local state without a ledgered repair path.
P0	Backend foundation	`VirtualAccountDepositReservationTransition`	`source-refs/sanmopia_web/application/controllers/api/Payment.php:123-158`, `source-refs/sanmopia_web/application/controllers/api/Payment.php:421-505`, `source-refs/sanmopia_web/application/controllers/api/Kcp.php:18-103`, `source-refs/sanmopia_web/application/models/Kcp_model.php:8-13`, `source-refs/sanmopia_web/application/models/Payment_model.php:166-215`, `source-refs/sanmopia_web/application/models/Payment_model.php:353-380`, `source-refs/sanmopia_web/application/models/Payment_model.php:512-734`, `source-refs/sanmopia_web/application/controllers/cli/Reservation.php:558-600`, `source-refs/sanmopia_web/application/controllers/cli/Reservation.php:741-827`, `source-refs/sanmopia_web/application/models/Reservation_model.php:2960-3031`	Virtual-account issue, deposit callback, expiry cron, deadline reminders, and notifications are coupled to raw KCP JSON. Source issue flow detects `pay_method == vcnt`, formats `va_date`, sends account/deadline messages, stores provider context, and changes payment status to waiting; KCP notification accepts only configured provider IPs, logs raw POST, treats non-`TX00` events and `op_cd == 13` cancel events as acknowledged/no-op, then finds payment rows by raw `order_no`/`tno`. It reads `ipgm_mnyx` and `noti_id` but the model matches only `order_no`/`tno`; duplicate handling is payment-row-state based (`already paid -> true`) rather than provider-notification-id based, cancel notifications leave no lifecycle fact, and deposit amount drift relies on the provider comment instead of comparing callback amount to the frozen payment row price. Deposit processing idempotently ignores already-paid rows, updates waiting reservation `입금대기 -> 예약` or `사전예약대기 -> 사전예약`, writes payment paid status and `DEPOSITED_DT = now()`, closes coupon virtual-account payments by issuing coupon entitlement, and sends mother/branch notices. Expiry cron queries `PAYMENT_CONTEXT.va_date` JSON and changes reservation status `14 -> 17` with a change-log row before a separate notice job; a different cron warns two days before expiry by re-reading bank/account/deadline/price from the same raw context. Backend foundation commit `097030f` adds `VirtualAccountPaymentLifecycle` and `VirtualAccountDepositReservationTransition`: typed issue/deposit/expired events, provider-order and transaction idempotency keys, provider paid-at time, deadline clock, expected payment/reservation revisions, payment-purpose-specific reservation transition trigger keys, audit events, and notification outbox keys. Public contracts reject raw KCP/status fields such as `PAYMENT_CONTEXT`, `ordr_idxx`, `tno`, `pay_method`, `RESERVATION_STATUS_LIST_ID_FK`, and Korean source labels. Balance/coupon virtual-account lifecycle events intentionally do not mutate reservation state. 2026-07-09 backend follow-up adds `VirtualAccountPaymentLifecycleDecisionStore`, `SupabaseVirtualAccountPaymentLifecycleDecisionStore`, and service-role-only table `sanmopia_virtual_account_payment_lifecycle_decisions`, persisting decision key, payment key, lifecycle action/state, expected/next payment revision, provider order/transaction/provider, paid/deadline timestamps, purpose, notification outbox keys, audit event key, and source evidence keys with RLS enabled. Stage DB migration was applied and verified with only service-role `select/insert/update`. Remaining proof: persist reservation-transition decisions, bind KCP/Kill Bill notification adapters with duplicate `noti_id`/amount/transaction tests, record cancel/non-`TX00` callbacks as ignored lifecycle facts, invoke the existing reservation state-transition engine by trigger key, dispatch Restate notification/audit workflows, replace cron JSON deadline scans with scheduled lifecycle jobs, prove reminder/expiry messages read the same frozen instruction amount and deadline that provider issue created, and cover expired-after-paid race plus reminder idempotency.
P1	Pending	`DocumentMailboxPostCommand`	`source-refs/sanmopia-admin/application/controllers/DataRoom.php:119-197`, `source-refs/sanmopia-admin/application/models/Data_room_model.php:25-202`, `source-refs/sanmopia-admin/static/js/data_room/other_post_write.js:1-108`	Data-room post/file authority is browser/controller state; backend must own branch 36/all/null recipient semantics, exclusions, attachment revisions, delete grants, and audit.
P1	Pending	`ReservationDocumentBundlePolicy`	`source-refs/sanmopia-admin/application/controllers/DataRoom.php:311-386`	Replace board-index/service-type hardcoded download bundles with versioned eligibility and item manifests.
P0	Partial	`CaregiverCandidateOrderingPolicy`	`source-refs/sanmopia-admin/application/models/Matching_model.php:31-32`, `:88-160`, `:718-847`; `source-refs/sanmopia_web/application/models/Manager_matching_model.php:58-151`, `:248-264`	Matching order differs by surface; freeze score, distance, transit, random tie seed, stale ODSAY refresh, pet exclusion, and source-surface policy inputs/results.

Lane C Source Feature Checklist Gaps

Legacy/source evidence	Old behavior to retire	Modern bounded context / slice	Missing or partial current path	Proposed improved abstraction
`source-refs/sanmopia-admin/application/controllers/Reservation.php`, `source-refs/sanmopia-admin/static/js/reservation_status/reservation_detail.js`	Broad reservation detail submit mutates profile, address, dates, caregivers, status, and memo, then tries to log after the fact.	`reservation_operations / reservation_collaboration`	Partial: `backend-repo/src/.../features/reservation_collaboration/` has workspace, journal, conflict, and Supabase RPC support; remaining gap is full actor capability coverage and every mutation group as a typed command.	`ReservationCollaborationCommand` with `expectedRevision`, field group, actor capability snapshot, conflict diff, resolution decision, realtime invalidation, and return-state token.
`source-refs/sanmopia_web/application/controllers/api/Payment.php`, `source-refs/sanmopia_web/application/models/Payment_model.php`	Payment-purpose, payer, coupon, provider, and refund side effects are inferred from request flags and source payment maps.	`pricing_settlement / customer_payment_instruction`, `payment_refund`	Partial: `ReservationPaymentWorkflow`, `payment_refund`, `killbill_payment_event`, and `killbill_admin_operation` exist; public completion/repair, virtual-account closeout, and receipt/refund artifact paths still need end-to-end proof.	Kill Bill `PaymentInstruction` and `RefundLifecycle` ports behind product-plan policy, with ledger-backed side effects and no PortOne-named domain/API abstraction.
`source-refs/sanmopia-admin/application/controllers/Calculate.php`, `source-refs/sanmopia-admin/application/controllers/DataRoom.php`, `Spreadsheet_model.php` export readers	Settlement rows, export files, branch acknowledgements, and external-counterparty status are coupled to mutable calculation/export paths.	`pricing_settlement / settlement_statement`, `settlement_data_room`, `branch_settlement_reconciliation_export`	Partial: statement commands, data-room artifacts, reconciliation export workflow, and settlement status projections exist; remaining gap is complete statement-line coverage and repair history surfaced through operations contracts.	`SettlementStatementWorkflow` with statement kind, line context, approval/acknowledgement state machine, export dataset revision, signed artifact grant, repair command, and transition audit.
`source-refs/sanmopia-manager/application/helpers/salary_helper.php`, `source-refs/sanmopia-admin/application/models/Matching_model.php`	Matching decisions and payroll amounts are recomputed from current read-time rows.	`caregiver_assignment / assignment_decision_evidence`, `pricing_settlement / caregiver_compensation`	Partial: candidate/evidence and payout foundations exist, but API exposure, worker persistence, and payroll statement readiness remain incomplete.	`CaregiverAssignmentDecisionEvidence` feeding `CaregiverPayoutInstruction` with grade snapshot, role slot, attendance facts, tax election, conflict evidence, and payout audit.
`source-refs/sanmopia_web/static/js/step3.js`, `reservation_calendar.js`, holiday management sources	Weekly service, extension, weekend, holiday, substitute-holiday, and branch-closure effects are calculated in UI/PHP branches.	`reservation_operations / service_calendar`, `service_period`, `holiday_policy_execution`	Partial: service-calendar policy and holiday audit foundations exist; missing gate is all quote, matching, report, refund, and settlement invalidation paths using the same frozen service-period plan.	`ServicePeriodPlan` and `HolidayPolicyExecutionAndImpactInvalidation` as backend projections consumed by portals only as read models.
`source-refs/sanmopia_web/application/views/mypage/reservation_document.php`, document spreadsheet/static templates	Numeric document ids, raw file paths, and direct download tokens leak document/template logic to views.	`document_reporting / printable_document`, `printable_template_version_manifest`	Partial: document catalog, Storage-backed template loading, HTML/PDF render artifacts, and signed grants exist; missing gate is complete source template manifest and bundle/ZIP artifact policy.	`PrintableTemplateVersionManifest` plus `DocumentRenderArtifactGrant` with service eligibility, template version, render request id, signed URL, revocation, and access audit.
`source-refs/sanmopia_web/application/controllers/api/Service.php`, branch/address sources	Address strings, branch ids, impossible-region flags, and consultation-only fallbacks decide serviceability at UI/API edges.	`branch_operations / service_area_policy`	Partial: branch service-area policy APIs and Supabase persistence exist; remaining gap is every booking, quote, support, and branch handoff path consuming a booking-bound decision snapshot.	`ServiceAreaDecisionSnapshot` with normalized address levels, branch scope, consultation-only reason, serviceability evidence, policy version, and SpiceDB-checked branch authority.
Sponsor, delegated payer, emergency contact, refund recipient, and document-visibility source branches	Family authority is inferred from account/profile/payment fields at each screen or controller branch.	`member_management / reservation_party_authority`, `pricing_settlement / refund_side_effect_ordering`	Partial: family account authority and payment communication routing are modeled; missing gate is one projection reused by booking, payment, refund, receipt, and document-download flows.	`ReservationPartyAuthoritySnapshot` that separates mother, sponsor, delegated payer, emergency contact, contact-only viewer, refund recipient, and document viewer permissions.
`source-refs/sanmopia-admin/application/views/reservation_status/reservation_detail.php`, office/branch operator sources	Screen-level status rules decide what HQ and branch actors can see or mutate.	`operator_access / actor_capability_projection`, `branch_operations / office_profile`	Partial: Supabase Auth, SpiceDB relationships, OPA gates, branch service-area APIs, and identity smoke flows exist; missing gate is full BranchOwner and HeadOfficeManager command visibility through one stable projection.	`ActorStageCapabilityProjection` keyed by Supabase Auth actor and SpiceDB relationship facts, returning allowed commands, disabled reasons, field visibility, branch scope, and audit context.
Cron/download/push/export source helpers and repair scripts	Background work runs as route helpers or scripts with weak retry, visibility, and correlation.	`platform / queue_workload`, `platform / observability_backpressure`	Partial: Supabase queue contracts, queue worker, Restate workflow status, and OTel collector wiring exist; missing gate is feature-by-feature workload declarations and load tests for queue oldest-age, DLQ, and workflow-blocked alerts.	`QueueWorkloadContract` with idempotency key, trace context, visibility timeout, retry policy, dead-letter repair command, worker concurrency limit, and OTel metric labels.

Architecture completion gates:

Actor Feature Checklist

This actor view uses the long-term role names from the C4 Actor Capability Layer. Entries here are backend obligations unless the note explicitly says otherwise. Detailed source evidence remains in the sections below.

HeadOfficeManager

ActorStageCapabilityProjection for HeadOfficeManager. Status: Partial. Required backend proof: Supabase Auth role facts, SpiceDB relationship facts, OPA policy decisions, disabled reasons, field visibility, command target, actor id, branch scope, and audit context returned through one stable read model before operations portal actions render.
HeadOfficeOperations settlement command surface. Status: Partial. Required backend proof: typed commands for request deposit, approve head office settlement, request arrears, close repair, and replay-safe retries with idempotency key, expected revision, actor capability snapshot, statement revision, and append-only transition audit.
Branch onboarding and office governance commands. Status: Partial. P01 domain and provider-neutral application command/query are GREEN through backend 8ac9ed9ca937e1521f984aa7de66bd7c3e64855b. The HQ authority adapter is GREEN at c4a19418109dd34ce1ba6364c8d1b4040bef9bb7 with server-owned profile/membership, explicit HQ root, and SpiceDB administer_headquarters binding. The strict actor/HQ/command-scoped current-result adapter is GREEN at 78781cff20216ebd13a0918be1319e72143b94dc; DB01-13 persistence plus the concrete four-RPC durable-store adapter are GREEN at 54974c2ba4d60db26f71b1313ee3070ff45deb98. Provider effects, runtime composition, actor UI, isolated HQ execution, and full provider cleanup remain unproved. Required backend proof: HeadOfficeManager-created branch profile, operator credential lifecycle, duplicate login-id decision, active/deleted office state, membership-fee policy, bank-account snapshots, brand asset lifecycle, and login audit events exposed through command/query APIs.
Data room, document export, and repair operations. Status: Partial. Required backend proof: configurable export templates, immutable artifacts, signed download handoffs, retry/rebuild state, repair request state, access audit, Supabase Storage/RLS binding, and no raw filesystem or query-string download path.
Policy, price, benefit, content, and analytics catalog administration. Status: Partial. Required backend proof: versioned catalog command APIs, authored-definition read models, activation windows, approval/audit workflow, report export projections, and runtime verification that portals consume server projections.

BranchOwner

ActorStageCapabilityProjection for BranchOwner. Status: Partial. Required backend proof: branch membership relationship, branch scope, allowed reservation/settlement/care-team commands, disabled reasons, retry/block state, and field visibility returned without portal-side status inference.
Reservation collaboration and conflict resolution. Status: Partial. Required backend proof: branch-scoped workspace open, journal, expected revision, stale-save conflict diff, field winner command, realtime projection invalidation, presence/session recovery, and audit timeline persistence. 2026-07-06 backend delta: ResolveReservationConflictHandler, Supabase conflict-resolution decision persistence, API authorization, and POST /reservation-collaboration-conflict-resolutions/{reservationId} now record actor, expected current revision, source audit ids, chosen winner per field, submitted/current/resolved values, and idempotency key. Remaining proof is portal wiring, realtime invalidation UX, and full audit timeline display.
CareManager assignment and availability decisioning. Status: Partial. Required backend proof: candidate snapshot, conflict read projection, unavailable-period persistence, optimizer input persistence, replacement continuity, assistant slot invalidation, final decision audit, and generated API/client exposure.
Branch profile, service area, bank account, content, and office assets. Status: Partial. Required backend proof: branch profile command/query APIs, service-area policy publish/decision APIs, service-area policy persistence, settlement-account snapshots, stamp/profile asset lifecycle, office-content scope rules, Supabase Storage/RLS policies, and HeadOfficeManager oversight gates. 2026-07-04 update: backend now exposes Supabase Auth + SpiceDB protected POST /branch-service-area-policy-revisions and POST /branch-service-area-policy-decisions, and contract exports matching OpenAPI schemas plus TS helpers so branch coverage is not decided by UI AREA_ACCEPT_TYPE_ID_PK numbers.
Branch settlement acknowledgement and operational dashboard. Status: Partial. Required backend proof: branch deposit acknowledgement, line acknowledgement, arrears payment confirmation, status-count dashboard, signed artifact handoff, branch visibility filtering, retry state, failed export state, and repair history projection.

Mother/FamilySponsor

ActorStageCapabilityProjection for Mother/FamilySponsor. Status: Partial. Required backend proof: family relationship facts, reservation lifecycle state, allowed next actions, disabled reasons, blocked-by-existing-reservation facts, document/payment readiness, visible charge summary, and field filtering through one customer-safe read model.
Reservation intake, care-plan, and charge freeze. Status: Partial. Required backend proof: booking operational context persistence, stay-plan catalog persistence, service due-date policy, address-scoped benefit decision, service-calendar invalidation, immutable charge snapshot, authorization, and command/query API wiring.
Payment product plan, pre-registration, receipt, and adjustment payment. Status: Partial. Required backend proof: catalog-driven payment product families, allowed methods, provider route, virtual-account expiry, refund/conversion policy, settlement participation, Supabase versioned catalog rows, Novu/Strapi communication workflow catalog alignment, signed receipt handoff, adjustment paid verification, and customer-safe payment summary APIs.
Document bundle, grant, delivery attempt, and access history. Status: Partial. Required backend proof: persisted document catalog/templates, bundle readiness, signed ZIP/artifact grants, resend/revoke controls, delivery retry state, recipient-visible access history, and customer-safe public handoff references.
Service-day review, final rating, assistant rating, and reward grant. Status: Partial. Required backend proof: persistence adapters, route binding, reward-ledger storage, readiness/action decisions, public/private review scope, and customer projection that does not depend on portal-only rating logic.
Partner benefit, coupon/gift shop, promotion, and campaign fulfillment. Status: Partial. Required backend proof: entitlement policies, purchase/payment linkage, recipient snapshots, resend/cancel state, provider delivery attempts, result artifacts, campaign audience policy, suppression/retry/dead-letter state, and repairable fulfillment audit.

CareManager

ActorStageCapabilityProjection for CareManager. Status: Partial. Required backend proof: assignment relationship facts, active service window, 90-day visibility policy, report/attendance obligations, payout/readiness state, blocked reasons, and field visibility returned by backend read models.
Self-service profile, credential evidence, media, account security, and office requests. Status: Pending. Required backend proof: credential evidence lifecycle, unavailable-period command API, profile/signature media storage, password/account hardening, branch-office request thread, bank-account handoff to payout, and RLS policies.
Matching preference profile and availability. Status: Partial. Required backend proof: persisted matching profile, pet/service/personality answers, versioned preference mutations, compatibility-signal integration, availability conflict projection, and assignment optimizer consumption.
Schedule, attendance, service records, and daily care reports. Status: Partial. Required backend proof: assignment-scoped schedule APIs, attendance idempotency by contract assignment key, service-record persistence/API, daily report submission persistence/API, notification outbox execution, and printable snapshot handoff.
Payout statement, tax election, bank account, and receipt acknowledgement. Status: Partial. Required backend proof: manager-facing payout statement API, revisioned receipt state event/projection persistence, bank-account edit proof, tax formula explainability, authorization gates, and full main/assistant operational screen support. Persistence proof now exists through sanmopia_caregiver_payout_receipt_state_events and sanmopia_caregiver_payout_receipt_states; bank-account edit proof now persists as CaregiverPayoutDestinationChangeAudit with full previous and adjusted destination snapshots, changed-field vocabulary, idempotency key, actor, target revision, participant RLS, realtime publication, FastAPI route, OpenAPI/TS contracts, and Supabase row type. Portal and admin/manager shared projection wiring remain open.
Education, notices, office request flow, news, referral, and events. Status: Partial. Required backend proof: caregiver content inbox, learning material state, event participation workflow, referral lead tracking, branch-scoped audience policy, notification state, request status, and repairable delivery audit.

Source Coverage

Admin/backoffice controllers and models inventoried: source-refs/sanmopia-admin/application/controllers/*, source-refs/sanmopia-admin/application/controllers/ajax/*, source-refs/sanmopia-admin/application/controllers/cli/*, source-refs/sanmopia-admin/application/models/*.
Mother/customer web controllers and pages inventoried: source-refs/sanmopia_web/application/controllers/*, source-refs/sanmopia_web/application/controllers/api/*, source-refs/sanmopia_web/application/controllers/cli/*, source-refs/sanmopia-user-old/src/pages/*, source-refs/sanmopia-user/src/pages/*.
Caregiver/manager web controllers and models inventoried: source-refs/sanmopia-manager/application/controllers/*, source-refs/sanmopia-manager/application/controllers/cli/*, source-refs/sanmopia-manager/application/models/*.
Native shell sources inventoried: source-refs/sanmopia_android/app/src/main/*, source-refs/sanmopia_ios/ios_sanmopia_app/*, source-refs/sanmopia_manager_android/app/src/main/*.
Runtime/data support sources inventoried: source-refs/sanmopia-docker/*, source-refs/sanmopia-price-table/*.
Kanboard renewal operations evidence inventoried through live JSON-RPC: project 산모피아 id 85, Kanboard v1.2.35, cards 776, comments 1507, subtasks 11, task files 233, task links 30. Summary is tracked in Kanboard Renewal Feature Improvements.

Runtime Test Data Hygiene

Stage smoke fixtures register cleanup ownership in Supabase. sanmopia_test_data_batches stores batch key, owner tag, source script, environment, expiry, status, and cleanup summary. sanmopia_test_data_references stores ordered cleanup references for public rows and Supabase Auth users. pnpm test-data:reap is a dry-run gate and pnpm test-data:reap:apply performs explicit confirmed deletion. pnpm doctor fails when a reachable stage contains expired active test-data batches, so repeated reservation, payment, and settlement smoke runs do not quietly create long-lived fixture debt.

2026-07-03 Source Survey Delta

Focused scan: legacy PHP and source-reference UX paths for booking/reservation, payment, settlement, caregiver matching/payroll, branch/HQ approvals, settlement data room, document/report generation, and branch/admin stale-data, history, and audit gaps. Status reflects read-only comparison against current contract/backend/frontend repo shape and this checklist; no modern code was changed.

Legacy source path/evidence	Modern bounded context / feature name	Implementation status	Migration priority	Notes
`source-refs/sanmopia-admin/application/controllers/Reservation.php:650-880`, `source-refs/sanmopia-admin/application/controllers/Reservation.php:930-1014`	`reservation_operations / ReservationCollaborationCommand`, `ReservationMutationKind`	Backend-backed	P0	Source one-submit save mutates birth data, service term, payment dates, caregiver roster, address, memo, and status, then writes a best-effort diff log after persistence. Collaboration backend now binds service term, payment date facts, service-address replacement, memo, branch handoff, service dates, and extra service days behind `expectedRevision`; HTTP stale-save tests prove these legacy save field groups return `409` conflict diffs instead of last-write-win. Final caregiver assignment is no longer accepted through collaboration broad-save: backend `ef0a510`, backend backstop `068632e`, and contract `936ed47` reject mutation kind `caregiver_assignment` and `caregiver_assignment.*` change-set fields at domain, HTTP, adapter, SQL RPC, TypeScript, and JSON Schema layers so roster writes must use care-team assignment commands.
`source-refs/sanmopia-admin/application/models/Reservation_model.php:2165-2303`, `source-refs/sanmopia-admin/application/controllers/ajax/Reservation.php:180-208`	`caregiver_assignment / CaregiverAssignmentDecision`, `CaregiverAssignmentTerm`, `AssignmentDecisionAudit`	Partial	P0	Main caregiver change sets other-area service, writes old/new manager log, and mutates reservation. Assistant caregiver replacement uses slot `SORT` and can delete linked sub-payout/salary rows. Modern roster persistence plus `AssignCaregiverFromCandidateSnapshotCommand`, `ClearAssistantCaregiverSlotCommand`, `CareTeamAssignmentHistoryReadModel`, `CareTeamCurrentRosterReadModel`, `GET /care-team-assignment-histories/{reservationBookingId}`, `GET /care-team-current-rosters/{reservationBookingId}`, `POST /care-team-assignment-decisions/assign-from-candidate-snapshot`, and `POST /care-team-assignment-decisions/clear-assistant-slot` now persist, read history, project active primary/assistant roster slots, and record branch/HQ assignment writes from frozen candidate or cleared assignment evidence with expected reservation/roster revisions, actor/reason/idempotency, previous assignment key, invalidation targets, Supabase RLS/service-role split, SpiceDB `assign_caregiver` permission, public TS/OpenAPI contract coverage, and collaboration broad-save rejection for `caregiver_assignment` writes through domain/adapter/SQL/contract guards. Backend `39a8eba` adds standardized downstream invalidation dispatch: payout projection refresh is queued through the existing admin payout PGMQ requester, and document projection invalidation is recorded through a typed document-reporting receipt command. Backend `6758b30` binds protected FastAPI command routes and persists document-projection invalidation receipts in `sanmopia_care_team_document_projection_invalidations`; contract `495d5cc` exposes command request/response schemas and helpers. Backend `5dd338b` queues typed service-use contract document render requests to `sanmopia_document_rendering`, and backend `3cdc86a` consumes those requests through a durable render worker that retries until the frozen render source is available and then stores the printable artifact. 2026-07-09 source guard follow-up: `CareTeamRosterAssignmentDecision` rejects legacy DOM authority fields `data-index`, `fmanager-name`, and `input-senior-manager-name`, so browser-selected roster ids cannot bypass backend candidate snapshots and assignment commands. Remaining migration: live E2E branch/HQ assignment smoke, render-source producer binding from roster/projection revisions, and storage/access grant issuance.
`source-refs/sanmopia-admin/application/models/Manager_model.php:2038-2088`, `source-refs/sanmopia-admin/application/models/Manager_model.php:2146-2180`	`caregiver_assignment / CaregiverAvailabilityWindow`, `CaregiverAssignmentConflict`	Partial	P0	Source denied days are mutable rows and schedule overlap is a boolean lookup. Backend conflict policy now checks unavailable windows, overlapping assignments, and replacement continuity before final assignment. Remaining proof: durable conflict-read exposure, optimizer inputs, and portal conflict UX.
`source-refs/sanmopia-manager/application/helpers/salary_helper.php:8-227`, `source-refs/sanmopia-manager/application/views/pay_info_detail.php:165-263`, `source-refs/sanmopia-manager/application/views/schedule/schedule_info.php:136-200`	`pricing_settlement / CaregiverCompensationQuote`, `CaregiverPayoutInstruction`, `CaregiverTaxElection`, `CaregiverVoucherAddOnTaxCutoverPolicy`, `CaregiverAdditionalServiceDayBasis`, `care_delivery / CaregiverServiceBalanceShareProjection`, `CaregiverPayoutAdjustmentAudit`, `CaregiverPayoutDestinationChangeAudit`	Partial	P0	Backend now issues payout instructions and models manager-facing payout statements plus receipt/exception/repair state commands from frozen compensation facts. Supabase persistence stores revisioned receipt-state events/current projections, append-only payout adjustment audits, and append-only payout destination change audits with idempotency keys, expected revision, full previous/adjusted payable amount or destination snapshot, changed-field vocabulary, participant RLS, and realtime publication. Public HTTP/API now records branch deposit acknowledgements, caregiver receipt acknowledgement/exception/repair commands, caregiver payout adjustment audits, and caregiver payout destination change audits through Supabase actor derivation plus SpiceDB reservation-booking permissions; contracts expose the matching paths, request/response schemas, and Supabase row types. Assistant branch-deposit acknowledgement now matches backend payout-slot identity with caregiver role and handoff order, covering source `SORT > 0` assistant row collision risk. 2026-07-05 follow-up: `CaregiverVoucherAddOnTaxCutoverPolicy` freezes voucher add-on taxable-base removal, tax category after-tax behavior, configurable business-income basis points, and legacy cutover date; `CaregiverAdditionalServiceDayBasis` freezes source service-day multipliers, service-day extension options, repeating option charge basis, custom service balance override, and profile-based voucher add-on deduction; `CaregiverServiceBalanceShareProjection` freezes care-team service-balance share, confirmation state, command availability, disabled reason, and payout statement reference for schedule items. 2026-07-07 follow-up: admin payout statement projection persistence now has Supabase projection/row tables, participant RLS, realtime publication, deterministic latest-revision read, row upsert store, and JSONB display/action roundtrip for multiple caregiver slots; FastAPI/TS projection read routes are bound; backend commit `e973097` queues admin payout projection refresh requests from branch deposit, receipt state, payout adjustment, and destination-change mutations through Supabase PGMQ queue `sanmopia_admin_payout_projection_refresh`. Backend commit `6e3bdfc` now executes projection rebuild worker from Supabase PGMQ by reloading frozen payout facts, computing the next projection revision, and saving the rebuilt admin projection. Backend commit `39a8eba` adds care-team assignment change as another projection refresh trigger, so primary/assistant assignment and assistant clear no longer leave admin payout projections stale. Remaining work: manager/branch/HQ screens without PHP/JS salary recalculation and E2E worker proof.
`source-refs/sanmopia-admin/application/controllers/Calculate.php:150-312`, `source-refs/sanmopia-admin/application/controllers/Calculate.php:155-190`, `source-refs/sanmopia-admin/static/js/calculate_detail.js:20-323`, `source-refs/sanmopia-admin/application/models/Payment_model.php:534-597`, `source-refs/sanmopia-admin/application/models/Payment_model.php:2861-2878`, `source-refs/sanmopia-admin/application/models/Payment_model.php:2977-3051`, `source-refs/sanmopia-admin/application/models/Payment_model.php:4312-4400`	`pricing_settlement / SettlementStatement`, `SettlementTransitionAudit`, `SettlementLineAcknowledgement`, `SettlementStatementManualRow`	Partial	P0	Command-ledger/idempotency foundation now covers HQ deposit request, branch deposit confirmation, HQ approval, arrears request, per-line acknowledgement, and HQ manual etc rows. Source UI posts one `FormData` blob containing selected normal/voucher rows, gift/cancelled-coupon rows, delivery flag, membership flag, manual etc names/counts/prices, actor type, board id, message, and memo, then sends it to one controller action for both HQ request and branch acknowledgement. `BranchSettlementDeliveryFee` now owns delivery-fee rate selection and line-item projection, but command/API binding must still route delivery acknowledgement through typed commands. Remaining migration must bind every source board mutation path to typed commands with row-level expected revision: membership due, delivery acknowledgement, cancelled gift coupon commission, selected detail rows, coupon rows, manual etc rows, message-to-branch, HQ-private memo, manual row audit, and rejection when selected row set/revision changed after page load.
`source-refs/sanmopia-admin/application/controllers/Calculate.php:337-430`, `source-refs/sanmopia-admin/application/controllers/Calculate.php:433-457`, `source-refs/sanmopia-admin/application/models/Payment_model.php:2657-2814`, `source-refs/sanmopia-admin/application/models/Payment_model.php:2816-2965`, `source-refs/sanmopia-admin/application/models/Payment_model.php:2916-2972`, `source-refs/sanmopia-admin/application/controllers/DataRoom.php:268-309`	`pricing_settlement / InterOfficeSettlement`, `ServiceOfficeTransfer`, `CustomerHandoffOffice`, `ReservationExternalCounterpartySettlementStatus`, `SettlementStatementKind`, `InterOfficeSettlementAcknowledgement`	Partial	P0	Backend aggregate, lookup key, and history reader exist. Inter-office settlement now projects branch-facing `inter_office_branch_share` payable lines and `inter_office_service_fee` receivable lines from frozen settlement lines, with service/customer branch ids and charged-branch fee payloads required before branch statement projection. This replaces source `RESULT_PRICE`, `FEE`, `ALL_PRICE`, and `PRICE * COUNT` view/controller arithmetic for other-area branch settlement evidence. Branch acknowledgement now accepts typed `InterOfficeSettlementAcknowledgement` through application/HTTP contracts, validates service-delivery versus customer-relationship side, actor, expected revision, dataset revision, and projected line ids, then stores the evidence in transition-audit metadata instead of trusting source `fbranch-type`. Settlement data-room workspace backend now uses canonical collection summaries and detail lookup-key selectors for external-counterparty, branch-to-HQ, HQ, and inter-office settlement, with service office, customer handoff office, settlement owner office, branch/HQ visibility, and expected revision carried separately from source `DANBEE_STATUS_FL`, `OTHER_OFFICE_STATUS_FL`, and `BRANCH_TYPE` ids. Do not collapse branch settlement, headquarters approval, external-counterparty export readiness, and inter-office service/customer-relationship branch roles into one status flag or one collection. Remaining proof: live external-counterparty/operator board persistence, UI actions, and source-specific readiness projection binding.
`source-refs/sanmopia-admin/application/controllers/DataRoom.php:30-94`, `source-refs/sanmopia-admin/application/controllers/DataRoom.php:119-212`, `source-refs/sanmopia-admin/application/controllers/DataRoom.php:218-250`, `source-refs/sanmopia-admin/application/controllers/DataRoom.php:268-386`, `source-refs/sanmopia-admin/application/controllers/ajax/DataRoom.php:17-240`, `source-refs/sanmopia-admin/application/controllers/Calculate.php:568-577`, `source-refs/sanmopia-admin/application/models/Data_room_model.php:25-203`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:15-58`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3741-3911`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3914-4198`, `source-refs/sanmopia-admin/static/js/data_room/form_reservation_list.js:6-47`, `source-refs/sanmopia-admin/static/js/data_room/form_reservation_list.js:225-262`, `source-refs/sanmopia-admin/static/js/calculate_detail.js:297-337`	`pricing_settlement / SettlementWorkspace`, `document_reporting / BranchResourcePost`, `SettlementDataRoomCollection`, `SettlementArtifactRequest`, `SettlementArtifactVersion`, `SettlementArtifactGrant`, `DownloadHandoffAudit`, `SettlementRepairRequest`, `OperatorReturnStateToken`, `BulkExportTemplatePolicy`	Partial	P0	Data-room backend/contracts now model request, build, ready artifact, repair, download handoff, deterministic caller-supplied ids, required grant idempotency keys with replay protection, timezone-aware domain datetimes, Pydantic application command/query DTOs, collection summary payloads, typed detail lookup-key payloads, and collection repair facts for mismatch/missing-board-row audits. Collection summaries now require `dataset_revision` and `projection_revision`, so status/count values are server/domain read-model values instead of source UI arithmetic over raw rows. Branch resource post backend now replaces other-post null-branch routing with explicit headquarters, branch, and all-branches sender/recipient scopes, revisioned attachment versions, retained/revoked post state, signed download grant commands, and audit entries for publish, supersede, revoke, retain, restore, and grant issue. New workspace tests prove no `dataType` switch, no source numeric status-id selection, stale expected-revision rejection, branch/HQ visibility checks, blank/missing grant idempotency rejection, naive datetime rejection, missing projection revision rejection, no raw-row summary payload, idempotency-key mismatch rejection for changed repair fact or grant intent, branch actor cannot publish as headquarters, revoked attachments cannot receive download grants, and stale workspace writes produce field-level `SettlementWorkspaceRevisionConflict` plus explicit operator `keep_current`/`apply_submitted`/`merge_explicit` decisions instead of overwrite. Public TS/JSON contracts now expose the same settlement workspace conflict response, resolution request, and resolution decision payloads. Backend workspace runtime now exposes `GET /settlement-data-room-workspaces/{workspaceCode}`, artifact request, repair request, grant handoff, return-state token, and conflict-resolution routes backed by `SettlementDataRoomWorkspaceApi`, `SupabaseSettlementDataRoomWorkspaceRepository`, `SupabaseSettlementDataRoomWorkspaceTemplatePolicyReader`, `SupabaseSettlementWorkspaceConflictResolutionDecisionStore`, `sanmopia_settlement_data_room_workspaces`, `sanmopia_settlement_data_room_template_policies`, and `sanmopia_settlement_workspace_conflict_resolution_decisions`. The runtime persists JSONB aggregate snapshots plus queryable collection/scope/revision columns, seeds a versioned `BulkExportTemplatePolicy`, resolves actor profile ids from backend-owned `sanmopia_member_profiles`, derives branch/HQ/workflow capabilities through SpiceDB, and stores idempotent explicit field-winner decisions so post-close workspace changes cannot rewrite an operator-visible stale-conflict result. 2026-07-06 follow-up: backend, Supabase migration, and TS contract now canonicalize data-room collections as `external_counterparty_settlement`, `branch_to_headquarters_settlement`, `headquarters_settlement`, and `inter_office_settlement`; source-era `head_office_settlement`, `danbee_settlement`, and `inter_branch_settlement` stay adapter/source evidence only. 2026-07-08 RBAC follow-up: workspace actor identity ignores Supabase `app_metadata.operator_profile_id`; a resolver reads member profile identity before SpiceDB authorization creates the domain actor. Source branch data-room pages still load board summaries directly, reuse mutable list filters/referrer/hash state, stream generated spreadsheets from hardcoded templates, and download completed files by raw GET redirect or hidden POST iframe. Remaining proof: browser workspace integration, Restate artifact-build worker binding to immutable templates/storage, signed Storage URL materialization behind grant references, repair/rebuild retry UX, no client-calculated status/totals, and no hidden POST-download hacks.
`source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4284-4595`, `source-refs/sanmopia-admin/application/controllers/cli/ReservationDocument.php:19-132`, `source-refs/sanmopia-admin/application/controllers/cli/ReservationDocument.php:140-245`	`document_reporting / ReservationDocumentTemplate`, `ReservationDocumentDelivery`, `DocumentAccessGrant`, `DocumentDeliveryAttempt`	Partial	P0	HTML/PDF artifact foundation exists, but full start/end document parity remains open: contract/receipt templates, static PDF notices, scheduled start/end email batches, manual resend/revoke controls, persisted ZIP bundles, signed-url issuing adapter, and recipient-visible access history.
`source-refs/sanmopia_web/application/views/about/terms.php:136`, `source-refs/sanmopia_web/application/views/about/terms.php:229`, `source-refs/sanmopia_web/application/models/Reservation_model.php:989`, `source-refs/sanmopia_web/application/models/Payment_model.php:383`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:1822`, `source-refs/sanmopia-admin/application/libraries/Kcppayment.php:31`	`pricing_settlement / ReservationCancellationRefundPolicy`, `RefundQuote`, `PaymentRefundIntent`, `PaymentRefundGatewayCommand`, `SupabasePaymentRefundLedgerStore`, `PaymentAdjustmentCatalog`, `ReservationCancellationRefundExplanationSnapshot`	Partial	P0	Source refund terms encode 14-day full refund, 24-hour full refund, 10% total-fee deduction, post-start used-fee plus 10%, gift 20k/40k, and delivery 5k deductions, while cancellation code mostly loops paid provider rows and sends KCP full-cancel requests. Backend foundation now quotes reservation cancellation refund from immutable facts, separates gift/delivery deductions from branch settlement gift fees, uses versioned adjustment catalog lines, calculates customer shortfall, blocks client-provided refund amount authority by deriving paid amount from the refund ledger, emits idempotent provider-neutral `PaymentRefundGatewayCommand` facts through `PaymentRefundIntent`, persists append-only refund ledger entries in Supabase, reads the latest active `PaymentAdjustmentCatalog` from `sanmopia_payment_adjustment_catalog_items`, exposes protected `POST /reservation-cancellation-refunds`, wires the runtime API through `KILLBILL_API_KEY`, and stores `refund_explanation_snapshot` JSON so the post-payment mother-visible refund result does not drift after later policy/catalog changes. 2026-07-05 follow-up: domain no longer owns KillBill HTTP method/path/body payloads; Supabase adapter maps `PaymentRefundGatewayCommand` into `billing_gateway_refund_command`, while Kill Bill request shape remains inside the provider adapter boundary. Public OpenAPI/TS contracts now include cancellation refund request/response schemas, validators, and `paymentChangeAdjustmentId` linking. New code cannot reintroduce provider-SDK or PG-console oriented command naming. Remaining migration: persist zero-gateway-refund quote decisions, link reservation cancellation workflow, restore coupon/benefit entitlements, notify customer/branch, and handle provider partial-cancel capability/status events.
`source-refs/sanmopia-admin/application/views/reservation_status/pre_reservation_detail.php:90-118`, `source-refs/sanmopia-admin/static/js/reservation_status/pre_reservation_detail.js:299-328`, `source-refs/sanmopia-admin/application/controllers/Reservation.php:1023-1088`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:5559-5595`, `source-refs/sanmopia-admin/application/libraries/Kcppayment.php:31-60`, `source-refs/sanmopia_web/application/models/Reservation_model.php:1012-1030`	`pricing_settlement / PreReservationCancellationRefundCommand`, `reservation_operations / PreReservationDetailCommit`, `SourcePreReservationStatusMapping`	Partial	P0	Admin pre-reservation detail save posts one status/contact/address/service-date form, regenerates reservation dates, and triggers pre-reservation refund only when posted status is `9`. The same source codebase still defines `18 사전예약취소`, while the admin pre-reservation selector exposes `9`, `15`, `16`, `17`, and `19` only. The pre-reservation refund lookup hardcodes payment type `6` and paid status `1`, extracts KCP context, and calls the gateway; Needs source confirmation whether any caller/library/trigger marks the payment row refunded, because the inspected path does not set status `2` while normal cancellation refund paths do. Backend foundation now removes source payment type/status ids from `PreReservationRefundPolicy`: `source_reservation_payment_acl.py` maps source payment type codes `1/2/3/6` and collection status codes `0/1` into `ReservationPaymentPurpose` and `PreReservationPaymentCollectionState` before creating `PreReservationPaymentCapture`; reservation payment summary projection reuses the same ACL instead of keeping a duplicate adapter dict. Remaining migration needs a dedicated pre-reservation cancel/refund command, explicit status mapping for `9` versus `18`, append-only refund ledger update, and a separate detail commit command for address/service-date/date-regeneration fields.
`source-refs/sanmopia_web/application/models/Reservation_model.php:463-486`, `source-refs/sanmopia_web/application/models/Reservation_model.php:2515-2630`, `source-refs/sanmopia_web/application/models/Reservation_model.php:2710-2747`, `source-refs/sanmopia-admin/application/models/Manage_system_model.php:52-109`, `source-refs/sanmopia-admin/application/controllers/ajax/ManageSystem.php:16-32`, `source-refs/sanmopia-admin/application/controllers/Reservation.php:1749`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:5376`, `source-refs/sanmopia_web/application/models/Report_model.php:324-339`, `source-refs/sanmopia_web/application/models/Report_model.php:451-466`	`reservation_operations / ServicePeriodCalculationPolicy`, `ServiceCalendarCompatibilityDecision`, `ReservationServiceTermPlan`, `HolidayPolicyVersion`, `ServiceDayOccurrence`, `ServiceCalendarImpactPlan`, `SourceServiceCalendarExtraOptionDecision`; `pricing_settlement / ReservationServiceCalendarQuote`, `ServicePeriodChargeContext`	Partial	P0	Source edit and new-reservation flows disagree on legacy weekend-shift duration, newer weekday-count duration, Wanju extension math, selected Saturday/holiday quantities, and report holiday exclusion. `HOLIDAY_TB` plus free-text `LIST_HOLIDAY_TYPE_TB` can record a substitute holiday name, but not source, announcement date, substitute-of relationship, branch scope, supersession, or whether a date is skipped service time versus selected paid extra service. Modern service calendar policy now emits policy-versioned `ServiceDayOccurrence` snapshots, `ServiceCalendarCompatibilityDecision` facts, and `ServiceCalendarImpactPlan` consumer facts for daily report selection, charge repricing, caregiver assignment review, refund requote, and settlement recalculation, so historical source end-date drift and downstream operational impact are explicit instead of hidden in UI/PHP recalculation. Supabase now persists plan compatibility fields, per-date occurrence rows, service-calendar impact fact rows, policy profile rows, and source add-date eligibility decision rows. Backend now exposes SpiceDB-protected `GET /reservation-service-calendar-impacts/{reservationBookingId}` with `impactKind` and `planCode` filters, backed by the latest/selected Supabase plan rows so charge, assignment, report, refund, and settlement consumers can read frozen service-calendar impact facts instead of UI totals. Settlement financial lifecycle now reads the latest settlement-recalculation impact facts and rejects branch/HQ settlement preparation unless the command carries matching service-calendar plan id, policy fingerprint, and impact fact ids; reservation cancellation refund now does the same for `refund_requote_required` before quoting, through shared Pydantic application models and one Supabase impact-reference reader instead of duplicated UI/backend lookup code. Assignment optimizer now rejects optimization unless `caregiver_assignment_review_required` service-calendar facts are acknowledged by booking id through a Pydantic impact reference and shared Supabase impact-reference reader. Daily-care-report print-data build now rejects output unless `daily_report_selection_required` service-calendar facts are acknowledged by reservation id through the same shared Pydantic impact reference and Supabase impact-reference reader. 2026-07-04 follow-up: `ReservationServiceCalendarQuotePolicy` now converts selected Saturday/holiday charge facts into effective-dated, branch/program-specific charge lines, carries impact plan/fingerprint/fact ids, adds the total to `ReservationPriceSummaryInput`, and feeds `ReservationPriceSummaryChargeFreezePolicy` without importing reservation-operations domain types into pricing. `SourceServiceCalendarExtraOptionDecision` now isolates legacy source labels `토요일 추가`, `휴일 추가`, and legacy duration-extension tokens plus `RESERVATION_ADD_DATE` codes `SAT`/`HOLI` into a Python backend adapter, feeding expected counts and profile-driven duration extension days into domain `ExtraServiceDaySelection` without leaking region tokens or string comparisons into UI or domain rules. `ExtraServiceDayReconciliationDecision` now freezes expected-vs-selected Saturday/holiday count mismatch lines, reason codes, warning messages, and policy fingerprint into the service-calendar plan snapshot and Supabase RPC payload, so UI cannot recompute extra-day anomalies from raw counts. 2026-07-04 source-dig follow-up found additional gaps and backend now covers them as foundation: `ExtraServiceDateEligibilityDecision` validates raw `RESERVATION_ADD_DATE` writes against the frozen plan range, selected occurrence, policy fingerprint, and source reference; `SaturdayHolidayCollisionPolicy` rejects source `SAT` rows when the same date is a holiday and requires the `HOLI` bucket; `SupabaseExtraServiceDateEligibilityDecisionStore` persists those decisions in backend-only Supabase source-evidence rows; `ServiceCalendarPolicyProfile` and `SourceServiceCalendarPolicyProfile` move source duration-extension terms into profile data with profile key, adjustment key, and frozen duration extension days on reservation calendar plans; `ReservationServiceOccurrenceObligationProjector` and `service_occurrence_evidence_key` bind attendance/reporting to generated occurrences instead of raw date rows. 2026-07-05 follow-up: `ServicePeriodChargeContext` now preserves stable `period_template_key`, `period_kind`, `service_calendar_policy_fingerprint`, optional `service_duration_profile_key`, and source `evidence_key` inside `ReservationServiceCalendarQuote`, while rejecting display labels such as “2 Week Service” as keys and keeping pricing free of reservation-operations domain imports. Still-open gaps: bind profile management APIs/operator screens, require occurrence evidence in application commands, support every historical duration-mode profile from admin/web source evidence, and complete anomaly acknowledgement plus runtime API/operator UI wiring. Remaining migration: bind daily-report workflows, persist and expose service-calendar charge-rate catalogs, and keep week service, extension, weekend, holiday, sudden substitute holiday, branch-defined holiday rules, extra-date eligibility, bucket collisions, source compatibility profiles, and attendance/report obligations out of scattered UI/PHP recalculation.
`source-refs/sanmopia_web/application/models/Reservation_model.php:2039-2145`, `source-refs/sanmopia_web/application/controllers/api/Service.php:323-325`, `source-refs/sanmopia_web/application/models/Reservation_model.php:2473-2501`, `source-refs/sanmopia-admin/application/config/constants.php:128-129`	`reservation_operations / ReservationExtensionPlan`, `ExtensionEligibilityDecision`, `ContinuationVoucherEligibilityDecision`, `ServicePeriodPlan.extension_of`; `pricing_settlement / ReservationExtensionQuote`	Backend foundation + contract	P0	Source extension copies a reservation into a linked new reservation and carries mutable address, delivery, matching, memo, and payment facts forward. Backend pricing foundation now has `ReservationExtensionQuotePolicy`, which preserves original/new reservation ids, extension sequence, previous service end, extension start, and a linked `ReservationServiceCalendarQuote` while deriving a fresh extension `ReservationPriceSummaryInput` instead of blindly copying mutable payment totals. 2026-07-05 follow-up: `ContinuationVoucherEligibilityDecision` now evaluates requested voucher service against frozen ancestor-chain facts, blocks any chain with a prior social-service voucher, persists query columns on the continuation link, and exposes TS/schema contracts so UI cannot infer voucher conversion from current-row state. 2026-07-07 follow-up: commit `7d5db21` adds `ContinuationDraftConflictFact` plus `PlanContinuationDraftCreationPayload`, so source delete-and-relink behavior is replaced by typed draft-state eligibility, idempotent planning, superseded-draft evidence, copied-fact audit references, and strict contract rejection of source table/status fields. Latest backend follow-up requires `branch_service_area_decision_evidence_id` when continuation copied facts include address or service-area evidence, preventing blind continuation address cloning. Modern migration must still persist immutable extension intent and copied-fact audit rows, bind extension branch coverage snapshot, charge/assignment invalidation, full command/API runtime binding, and operator/customer UX without blind row copy.
`source-refs/sanmopia_web/static/js/mypage/reservation.js:336-421`, `source-refs/sanmopia_web/static/js/mypage/reservation.js:515-593`, `source-refs/sanmopia_web/application/models/Reservation_model.php:1091-1111`, `source-refs/sanmopia_web/application/controllers/api/Reservation.php:86-239`, `source-refs/sanmopia_web/application/models/Report_model.php:267-391`, `source-refs/sanmopia_web/application/models/Report_model.php:394-518`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:1768-1792`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:1888-1892`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4040-4045`, `source-refs/sanmopia-admin/application/models/Statistics_model.php:875-893`, `source-refs/sanmopia-admin/application/models/Payment_model.php:228-231`, `source-refs/sanmopia-admin/application/config/constants.php:130-131`	`reservation_operations / ServiceSuspension`, `SuspensionRequest`, `EffectiveStop`, `ResumeBoundary`, `ServiceSuspensionImpactPlan`	Partial	P0	Source stop behavior is customer stop request status `12`, admin-confirmed stopped status `13`, request rows, branch Alimtalk, and report logic that parses `RESERVATION_CHANGE_LOG` JSON for stop start/end. No first-class source pause/resume state was found; resume is inferred when later change-log `BEFORE_DATA` contains status `13`. Backend foundation now models durable suspension request, approval, resume boundary, affected service dates, and impact commands for service calendar, caregiver assignment, pricing/settlement, refund quote, daily care report, customer communication, and stopped-voucher settlement eligibility using source `DATEDIFF(SERVICE_END_DT, SERVICE_START_DT) >= 3` elapsed-span semantics. DailyCareReportServiceSuspensionWindowPayload now lets backend validation allow the stop day as the final report date while blocking later suspended service dates, so report eligibility no longer depends on `RESERVATION_CHANGE_LOG` string parsing. Remaining migration: persist interval rows, bind stop confirmation and resume as revision-checked reservation collaboration mutation kinds, make stop day the final report/export day, exclude suspended days from report selection, reset product coupons once on stop transition, wire settlement/data-room readers to `ReservationSettlementEligibilityRule`, and log stale stop/resume conflicts through workspace conflict events.
`source-refs/sanmopia-admin/application/models/Reservation_model.php:1873-1880`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:1888-1892`, `source-refs/sanmopia-admin/application/models/Coupon_model.php:63-87`, `source-refs/sanmopia-admin/application/models/Coupon_model.php:97-157`, `source-refs/sanmopia-admin/application/models/Coupon_model.php:218-323`, `source-refs/sanmopia-admin/application/models/Coupon_model.php:935-958`, `source-refs/sanmopia_web/application/models/Reservation_model.php:989-1066`, `source-refs/sanmopia_web/application/models/Coupon_model.php:530-553`	`pricing_settlement / ReservationPromotionSideEffectPlan`, `PlanReservationPromotionSideEffectHandler`, `ProductCouponResetPolicy`, `ReservationCouponRestorePolicy`, `PromotionEntitlementOutbox`; `customer_engagement / BenefitFulfillmentCancellation`; `pricing_settlement / RefundSideEffectPlan`	Partial	P0	Refund amount snapshot now exists, but source also couples stop/cancellation to product-entitlement hard delete/reissue, used-reservation-entitlement restore, benefit cancellation, payment refund, point/shop grant reversal, and delivery/gift side effects. On status `13` stop transition or status `9` cancellation, admin reset deletes existing product coupon rows only for normal-service reservations and republishes from `MANAGER_ATTENDANCE_TB`: no product coupon for `<=2` attended days, one-week `PRODUCT1` 20,000 coupon for `3-7`, and two-week `PRODUCT2` 30,000 coupon for `>=8`, with immediate `USER_COUPON_TB` grant and `+6 month` expiry. Backend domain now replaces product hard-delete/reinsert with `ProductCouponResetPolicy` and replaces `USER_COUPON_TB.USE_FL/USE_DT` flag reset with actor-aware `ReservationCouponRestorePolicy` commands that reuse `PromotionEntitlement.restore`. Backend application now adds `PlanReservationPromotionSideEffectHandler`, which composes product reset and cancellation-only reservation coupon restore into a persistable `ReservationPromotionSideEffectPlan` and rejects service-stop coupon restore ids so status `13` cannot reopen used reservation coupons. Supabase now persists plan snapshots in `sanmopia_reservation_promotion_side_effect_plans` and command outbox rows in `sanmopia_promotion_entitlement_outbox_entries`, with generated database types updated from the stage CLI. Remaining migration: `ReservationOperationFollowUpWorkflow` binding for stop/cancel, outbox worker execution for entitlement cancellation/issue/restore, benefit/point/shop/delivery side effects, customer-visible ledger/read models, and repair commands instead of controller-coupled deletes or flag flips.
`source-refs/sanmopia-admin/application/controllers/Reservation.php:1531-1605`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:823-852`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:5458-5496`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:5560-5595`, `source-refs/sanmopia_web/application/models/Reservation_model.php:1295-1305`, `source-refs/sanmopia-admin/application/models/Payment_model.php:220-279`, `source-refs/sanmopia-admin/application/models/Payment_model.php:534-752`, `source-refs/sanmopia-admin/application/models/Payment_model.php:860-940`, `source-refs/sanmopia-admin/application/models/Payment_model.php:1309-1333`, `source-refs/sanmopia-admin/application/models/Payment_model.php:1561-1568`	`pricing_settlement / PaymentProductPlan`, `CustomerSharePaymentSchedulePolicy`, `PaymentSettlementLineTemplate`, `PaymentProductCommunicationRoute`, `PaymentProviderRouteFeeSnapshot`, `PaymentPurpose`, `SettlementLineKind`, `SettlementParticipationPolicy`	Partial	P0	Source product behavior is hidden in payment table ids, coupon type codes, fixed voucher fee `15000`, fixed coupon fee bands `5000/10000/20000/30000`, payment-version customer-share splitting, notification template branches, and settlement-board/type branching. Backend now exposes a Supabase-session-protected `PaymentProductPlan` catalog through `GET /payment-product-plans` and `GET /payment-product-plans/{planCode}` with product family, allowed methods, obligation purposes, provider route, settlement participation, realization timing, refund/conversion policy, virtual-account expiration policy, backend-owned `PaymentSettlementLineTemplate` rows, and `PaymentProductCommunicationRoute` rows. Supabase persists versioned active/effective catalog rows in `sanmopia_payment_product_plan_catalog_items`; catalog v2 adds `settlement_line_templates` JSONB with voucher fixed commission `15000`, gift-coupon commission bands `5000/10000/20000/30000`, amount basis, policy reference, and applicability condition; catalog v3 adds `communication_routes` JSONB with trigger, recipient, provider workflow key, SMS fallback, message purpose, and optional applicability condition for customer-share, pre-reservation, service-balance, gift-coupon, and payment-change notices. The Pydantic adapter derives the same plan book used by Kill Bill pre-registration, so UI must select a backend plan instead of deriving product meaning from payment purpose, table ids, or notification string switches. 2026-07-04 follow-up: `PaymentProviderRouteFeeSnapshot` now binds the selected product plan, provider routing key, settlement participation, ledger recognition timing, fee recognition basis, settlement line targets, frozen customer-visible behavior, and `PaymentMethodFeePolicy` quote into the `POST /reservation-payment-pre-registrations` response. `sanmopia_payment_records` now stores nullable provider-route/method-fee snapshot columns for new pre-registrations, and the contract requires `paymentProductPlanCode` plus `providerFeeSnapshot`, preventing UI-side amount/fee reconstruction after catalog changes. `PlanPaymentCommunicationDispatchHandler` now converts payment catalog routes plus recipient facts into durable dispatch intents, and `SupabaseCommunicationDispatchStore` persists catalog-backed dispatch requests plus provider dispatch event audit rows. 2026-07-05 follow-up: `CustomerSharePaymentSchedulePolicy` now models voucher customer-share payment version `0` as `>100000` deposit/balance split, `<=100000` deposit-only, version `>=1` single obligation, and zero-amount provider closeout; TS/Pydantic contracts expose the backend decision so UI cannot split totals. Remaining migration: bind payment workflow runtime invocation, virtual-account instruction variables, queue/provider execution, booking/settlement persistence, and hidden source payment-type adapter edges to these catalog and schedule decisions.
`source-refs/sanmopia_web/static/js/step3.js:198-474`, `source-refs/sanmopia_web/static/js/step3.js:766-831`, `source-refs/sanmopia_web/static/js/step3.js:1148-1179`, `source-refs/sanmopia_web/application/models/Reservation_model.php:1115-1373`, `source-refs/sanmopia_web/application/views/reservation/retc.php:45-200`, `source-refs/sanmopia_web/application/views/modal/modal_change_payment.php:1-92`, `source-refs/sanmopia-admin/application/views/reservation_status/pre_reservation_price_table.php:1-120`, `source-refs/sanmopia-admin/application/controllers/ajax/Reservation.php:142-161`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:1579-1677`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:1627-1652`, `source-refs/sanmopia-admin/static/js/reservation_status/reservation_add.js:1367-1373`, `source-refs/sanmopia-admin/application/controllers/Reservation.php:849-859`, `source-refs/sanmopia-admin/application/controllers/Reservation.php:1243-1251`, `source-refs/sanmopia-admin/application/controllers/Reservation.php:1531-1593`, `source-refs/sanmopia_web/application/models/Payment_model.php:383-441`, `source-refs/sanmopia-admin/application/models/Payment_model.php:3383-3386`, `source-refs/sanmopia-admin/application/models/Payment_model.php:3458-3461`	`pricing_settlement / ChargeAdjustmentPolicy`, `PaymentAdjustmentCatalog`, `DiscountAdjustment`, `AdditionalChargeAdjustment`, `PartialRefund`, `CouponPrepaymentQuote`, `PreReservationCreditPolicy`, `ManualReceiptCloseout`, `ReservationPriceSummaryChargeFreezePolicy`, `FinalizeReservationChargeFromPriceSummaryHandler`, `ReservationServiceCalendarQuote`, `ReservationExtensionQuote`	Partial	P0	Source computes discount, coupon/pre-reservation deduction, regional support, extra-service charges, rental/delivery, service balance, payment-change amount, and refund state across browser `inputList` traversal, DOM `data-price` sums, PHP models, views, ajax controllers, and gateway loops. Modern replacement must centralize every customer-visible discount, additional charge, custom service-balance override, partial refund, and zero-gateway-refund decision in catalog-backed backend quote/ledger lines. UI may render only frozen adjustment snapshots with catalog version, source evidence key, actor/reason, idempotency key, and settlement impact; UI-observed reservation/payment totals are diagnostics only, not financial authority. 2026-07-04 follow-up: backend now freezes `ReservationPriceSummaryInput` through `ReservationPriceSummaryChargeFreezePolicy` into `FinalizedReservationChargeSnapshot`, with payable lines `mother_user_fee_due` and `service_balance_due` plus reference evidence for gross price, government support, regional benefit, coupon, pre-reservation payment, additional/rental charges, voucher service-balance add-on, voucher in-home user-fee change, and displayed discount. `FinalizeReservationChargeFromPriceSummaryHandler` opens and saves the financial lifecycle from that frozen summary, so post-payment mother-visible charge no longer replays UI/PHP arithmetic after pricing policy changes. `ReservationServiceCalendarQuotePolicy` now turns weekend/holiday extra-service charge facts into versioned quote lines before the summary is frozen, and `ReservationExtensionQuotePolicy` derives extension pricing from a new extension chain fact instead of copied payment rows. 2026-07-05 follow-up: `PaymentChangeRefundLink` now links payment-change adjustments to refund ledger entries through domain/application facts and a Supabase FK column. Newly strengthened remaining gaps: coupon used during pre-reservation must settle/refund in a distinct pre-reservation phase, admin manual receipt must consume frozen pre-reservation credit/coupon facts instead of raw `PRERESERVATION_PRICE`, refunded rows stay immutable, type `1/2/3` manual rows upsert idempotently, admin manual receipt cannot create paid rows from browser `service_before_price` or `service_balance_price` without audited expected amount, reason, and operator identity, and detail-save payment-date commands must mutate only the targeted payment type so balance cannot reuse a deposit date. Remaining abstraction gaps from source digging: `CouponPrepaymentQuote`, `PaymentAdjustmentQuote`, `VoucherInhomeAddOnQuote`, `ServiceBalanceOverrideDecision`, and `PaymentCloseout`.
`source-refs/sanmopia_web/application/views/service/step1.php:91-213`, `source-refs/sanmopia_web/application/models/Reservation_model.php:314-374`, `source-refs/sanmopia_web/application/controllers/api/Service.php:75-81`, `source-refs/sanmopia_web/application/controllers/api/Payment.php:91-92`, `source-refs/sanmopia_web/application/models/Payment_model.php:570-704`	`member_management / FamilySponsorRelationship`, `reservation_operations / ReservationBookerBeneficiarySnapshot`, `pricing_settlement / PayerSnapshot`	Partial	P0	Source reservation intake binds reservation ownership and payment notices to `USER_ID_FK`, `USER_NM`, and `CELLPHONE`, while `EMERGENCY_CELLPHONE`, `RELATION`, and `RELATION_ETC` are contact fallback fields. Backend/contract now expose family-account authority decisions for reservation sponsor booking, delegated reservation payment, and care-history access. Supabase persistence separates `sponsor_member_id`, `payer_member_id`, `grantee_member_id`, and `mother_member_id`; API derives the acting member from Supabase Auth `app_metadata.member_id` and never accepts sponsor/payer/grantee ids in request bodies. Payment closeout dispatch resolution now derives delegated reservation payer recipients from active `sanmopia_family_payment_delegations` facts and leaves ambiguous multiple-payer grants unresolved. Catalog v4 adds payer payment-complete workflow routes for delegated reservation payment products. Gift-coupon user receivers, phone-only gift receiver contacts, and primary/secondary branch payment notice contacts now resolve from backend snapshots/policies instead of UI strings, fake user ids, branch-id hardcoding, or sorted membership selection. Phone-only receiver provider dispatch uses `sanmopia_payment_direct_recipient_contact_snapshots` plus contact-only `sanmopia_direct_contact_communication_dispatch_requests`. Remaining migration: booker/beneficiary snapshot on booking workflow, emergency contact as contact-only data, consent authority, payment liability, document visibility, and refund recipient snapshots. Do not infer sponsor authority from phone ownership or emergency-contact relation text.
`source-refs/sanmopia_web/application/models/Branch_model.php:38-144`, `source-refs/sanmopia-admin/application/models/Branch_model.php:288-334`, `source-refs/sanmopia-admin/application/models/Branch_model.php:337-426`, `source-refs/sanmopia-admin/application/models/Branch_model.php:590-606`, `source-refs/sanmopia_web/application/controllers/api/Service.php:792-811`, `source-refs/sanmopia_web/application/models/Reservation_model.php:2113-2137`, `source-refs/sanmopia_web/application/models/Reservation_model.php:2235-2255`	`branch_operations / BranchCoverageDecision`, `AddressMatchRule`, `BranchServiceAreaPolicy`, `CoverageOverride`, `BranchServiceAreaDecisionSnapshot`	Backend + contract	P0	Source address matching uses fallback address depths, special split-address handling, possible/consultation/impossible rules, hard-delete service area mutation, local other-branch caregiver rejection, and continuation address copying. Backend/contract now expose branch service-area policy publication and decision APIs with Supabase actor, SpiceDB manage/view permission, rule revision, address-provider evidence, matched rule, and semantic policy kind. The decision API records `BranchServiceAreaPolicyDecision` snapshots into `sanmopia_branch_service_area_address_evidence` with booking id, decision code, address evidence, matched rule reference, coverage profile key, and service-calendar policy profile key so later policy changes do not rewrite booking-time branch ownership evidence. 2026-07-07 follow-up: reservation booking start now accepts `serviceAddress`, resolves the active branch policy in the backend, rejects unavailable coverage before booking, records the decision, and serializes a frozen `branchCoverageDecision` into Restate workflow input/contracts for replay. Continuation draft creation now rejects address/service-area copied facts without branch coverage evidence. Service-term mutation now rejects post-booking service-area profile changes unless the command carries `branch_service_area_decision_evidence_id`. Remaining migration: bind second-period and extension workflows to the same frozen decision path, persist continuation draft plans through runtime/API paths, add the precise `reservation_service_address_id` link, then route branch transfer, other-area override, pricing, matching, and conflict audit consumers through the frozen decision.
`source-refs/sanmopia-admin/application/controllers/Reservation.php:415-431`	`reservation_operations / OperatorFinancialMutationLockPolicy`, `ActorStageCapabilityProjection`, `ReservationFinancialFieldLock`	Partial	P0	Backend now replaces source `cantSave` with field-level `ReservationFinancialFieldLock` decisions for price version, service balance, payment date, and reservation status. `OperatorFinancialMutationLockPolicy` owns service-end-plus-grace-day locking, branch final-state locking, dated waiting-deposit cancellation and stopped-status edit exceptions, stage capability checks, source anchors, and stable lock reason codes. `POST /operator-financial-mutation-lock-decisions/{reservationId}` derives `actorKind` from authenticated branch/HQ actor context instead of accepting it from the portal, and returns `policyVersionLabel`, required capabilities, message keys, and source evidence. Remaining migration: bind the preview and every save command to a Supabase current-state reader with expected revision, persist audit facts for overridden locks, and add branch/HQ override workflow. Portal views must not decide whether a BranchOwner can mutate price, service balance, payment date, or status.
`source-refs/sanmopia-admin/application/controllers/Administrator.php:203-219`, `source-refs/sanmopia-admin/application/models/Payment_model.php:2565-2654`, `source-refs/sanmopia-admin/application/models/Payment_model.php:2620-2642`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:1769-1817`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:2956-3014`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:3030-3036`	`pricing_settlement / ManualReceiptCommand`, `SettlementBackfillRepairCommand`, `SettlementPayoutBackfillCloseout`	Partial	P1	Backend now has protected repair command foundation with HQ actor enforcement, reason, idempotency replay protection, expected revision, paired before/after facts, workflow impact note, and append-only audit records. Remaining gaps: protected manual-settlement contract/UI, authorization policy binding, Supabase audit proof, and repair executors that mutate only targeted payment/settlement rows through expected-revision checks. Status transition backfill must create branch-settlement rows once with expected reservation revision and settlement-impact event; salary/payment-complete backfill must upsert payout rows idempotently and auto-complete only after revision-checked service-balance and salary facts exist.
`source-refs/sanmopia-admin/application/controllers/cli/Manager.php:126-237`, `source-refs/sanmopia-admin/application/models/Manager_model.php:2038-2143`	`caregiver_performance_recognition / CaregiverGradeRecalculation`, `CaregiverCredentialEvidence`	Partial	P1	Performance-recognition contracts now have Supabase-persisted grade recalculation history plus API/HTTP reads for operator audit. Remaining gaps: scheduled recalculation runner, premium exclusion rules, score/class mismatch warning UX, credential media replacement audit, and frontend history view.
`source-refs/sanmopia-admin/application/views/local_calculate_central_history.php:31-75`, `source-refs/sanmopia-admin/application/views/table_local_cal_central_history.php:1-39`, `source-refs/sanmopia-admin/static/js/form_reservation_list.js:225-247`, `source-refs/sanmopia-admin/application/controllers/Calculate.php:460-578`, `source-refs/sanmopia-admin/application/controllers/DataRoom.php:311-386`	`branch_admin_ux / ReturnStateToken`, `SettlementHistoryReadModel`, `DownloadHandoffAudit`, `SettlementRepairHistoryView`	Partial	P1	Reservation collaboration now handles stale-save/draft events. Branch settlement/export frontend now removes URL token coupling and uses authenticated settlement/export reads plus signed download handoffs. Remaining gaps: durable list filters, return-state tokens where still useful, repair-history UI, retry state, failed export state, signed-download expiry refresh, and branch/HQ visibility filtering.

2026-07-05 Acceptance Vocabulary Delta

Read-only follow-up mining found broad checklist rows that still need sharper acceptance vocabulary before implementation work is considered done. These are backend ownership obligations; portal/admin UI may render snapshots but must not derive the authority values.

Service duration is profile-driven, not weeks * 7. Status: Partial. Evidence: source-refs/sanmopia-admin/application/config/constants.php:98, source-refs/sanmopia-admin/application/views/manager/manager_pay_detail.php:16-22, source-refs/sanmopia-admin/application/controllers/Reservation.php:380-381, source-refs/sanmopia-admin/application/models/Reservation_model.php:4146-4247, source-refs/sanmopia-admin/application/models/Reservation_model.php:5379-5418, and source-refs/sanmopia_web/static/js/step3.js:861-897. Required vocabulary: ServiceDurationProfile, VoucherWeekLength, ServiceEndDatePolicy, ExtraServiceDateSelection, and RegionalDurationBenefit. Backend domain now freezes voucher five-day week basis, service-end rollback policy, source evidence key, profile key, and regional duration extension on ServiceCalendarPlan. Supabase now persists service_duration_profile_key, duration_profile_evidence_key, and service_end_date_policy on sanmopia_reservation_service_calendar_plans through the service-calendar snapshot RPC. Acceptance proof still needs operator profile management API/UI and command binding from every reservation create/change path.
Continuation reservations are linked booking chains, not flags. Status: Backend foundation + contract. Evidence: source-refs/sanmopia_web/application/models/Reservation_model.php:2051-2223, source-refs/sanmopia-admin/application/models/Reservation_model.php:3690-3704, source-refs/sanmopia_web/application/models/Reservation_model.php:2431-2449, source-refs/sanmopia_web/application/controllers/api/Service.php:433-439, source-refs/sanmopia_web/application/controllers/api/Service.php:548-555, and source-refs/sanmopia_web/application/models/Manager_model.php:176-197. Required vocabulary: ReservationContinuationLink, ContinuationEligibility, ContinuationBookingClone, and ContinuationCaregiverCarryoverDecision. Backend domain now represents original booking id, continuation booking id, sequence, copied-fact audit key, continuation eligibility, same-caregiver carryover decision, and branch service-area decision evidence as first-class facts. Supabase now stores backend-owned sanmopia_reservation_continuation_links rows with a Pydantic link_snapshot, original/new booking ids, copied-fact audit key, eligibility, same-caregiver carryover reason/source evidence, optional branch coverage evidence, and operator-review flag. 2026-07-07 follow-up: backend commit 7d5db21 adds ContinuationDraftConflictFact, decide_continuation_draft_eligibility, and PlanContinuationDraftCreationPayload so continuation draft creation distinguishes no prior link, missing linked draft, replaceable writing draft, and active/submitted duplicate blocking. The Pydantic contract records idempotency, superseded draft id, copied-fact audit key, cloned-fact keys, caregiver carryover, optional voucher eligibility, and link output only when cloning is allowed; it rejects source relink/status fields such as RESERVATION_CONTINUE_TB, ORIGINAL_RESERVATION_ID_FK, NEW_RESERVATION_ID_FK, RESERVATION_STATUS_LIST_ID_FK, PROCESS_NO, MANAGER_ID_FK, MANAGER_SCHEDULE_CHECK_FN, and 예약작성중. Latest backend contract proof rejects address/service-area copied facts unless the draft carries frozen branch coverage evidence. Acceptance proof still needs collaboration command binding, persisted copied-fact audit detail rows, caregiver schedule reader integration, Supabase draft-plan persistence, and customer/admin read APIs.
Booking consultation gate is a frozen decision, not a reused CONSULTING_FL flag. Status: Backend-backed foundation. Evidence: source-refs/sanmopia_web/application/controllers/api/Service.php:53-60, source-refs/sanmopia_web/application/models/Reservation_model.php:2235-2301, source-refs/sanmopia_web/application/controllers/api/Service.php:425-430, source-refs/sanmopia_web/application/controllers/api/Service.php:540-545, source-refs/sanmopia_web/application/controllers/api/Service.php:705-719, source-refs/sanmopia_web/application/controllers/Service.php:602-623, source-refs/sanmopia_web/application/views/service/reservation_check_data.php:22-35, source-refs/sanmopia_web/application/views/service/reservation_check_data.php:147-218, and source-refs/sanmopia_web/static/js/step2.js:476-482. Required vocabulary: ReservationConsultationGateDecision, ReservationConsultationReason, ConsultationCustomerCopySnapshot, BookingMatchingRecommendationEligibility, and PriceVersionRolloverConsultationRule. Modern foundation now records phase-specific reason facts for consultation service area, second address, multi-baby, picked caregiver, birth-after, service-start proximity, continuation override, and price-version rollover evidence with customer-copy and matching-recommendation eligibility snapshots. Remaining work: persist the decision in Supabase and bind booking status, matching suppression, payment handoff, and customer UI to the frozen decision instead of mutable source flags.
Payment/refund authority includes custom override paths. Status: Partial. Evidence: source-refs/sanmopia_web/application/models/Reservation_model.php:1120-1205, source-refs/sanmopia_web/application/models/Reservation_model.php:1262, source-refs/sanmopia_web/application/models/Reservation_model.php:1348, source-refs/sanmopia_web/application/views/mypage/item/reservation_fee_table.php:80-95, source-refs/sanmopia_web/application/views/mypage/item/reservation_fee_table.php:335-358, source-refs/sanmopia-admin/application/controllers/Reservation.php:486-503, source-refs/sanmopia_web/application/models/Payment_model.php:383-423, and source-refs/sanmopia_web/application/models/Payment_model.php:856-896. Required vocabulary: ReservationChargeLine, ExtraServiceChargeBasis, CustomBalanceOverride, VoucherPureAdditionalServiceBalance, PaymentChangeIntent, and RefundInstruction. Acceptance proof: discounts, surcharges, partial refunds, operator overrides, and gateway refund commands are catalog-backed ledger facts, not UI totals.
Reservation state side effects are follow-up plans, not a lifecycle catch-all component. Status: Partial. Evidence: source-refs/sanmopia-admin/application/models/Reservation_model.php:1769-1916, source-refs/sanmopia-admin/application/models/Reservation_model.php:1873-1880, source-refs/sanmopia-admin/application/models/Reservation_model.php:1888-1892, source-refs/sanmopia-admin/application/models/Coupon_model.php:63-157, source-refs/sanmopia-admin/application/models/Coupon_model.php:935-958, source-refs/sanmopia_web/application/models/Reservation_model.php:989-1112, and source-refs/sanmopia_web/application/models/Coupon_model.php:530-553. Required vocabulary: ReservationStateTransitionPolicy, ReservationOperationPlan, ReservationLifecycleSideEffectPlan, ReservationOperationFollowUpWorkflow, ReservationPromotionSideEffectPlan, PlanReservationPromotionSideEffectHandler, and PromotionEntitlementOutbox. Acceptance proof: cancel, stop, payment, communication, settlement, and care-delivery follow-up actions are persisted with idempotency keys and workflow status; stop and cancel share product entitlement reset planning, but only cancellation restores used reservation entitlements. Source status numbers, source table flags, and provider-specific payment names stay adapter/evidence data, not public contract or component names.
Settlement data room is a workflow workspace. Status: Partial. Evidence: source-refs/sanmopia-admin/application/views/nav/nav_side.php:425-439, source-refs/sanmopia-admin/application/views/nav/nav_side.php:501-529, source-refs/sanmopia-admin/application/controllers/DataRoom.php:216-308, source-refs/sanmopia-admin/application/views/table/data_room/table_calculate_danvi.php:10-49, source-refs/sanmopia-admin/application/models/Payment_model.php:2526-2541, source-refs/sanmopia-admin/application/models/Payment_model.php:2786-2828, and source-refs/sanmopia-admin/application/models/Payment_model.php:2891-2906. Required vocabulary: SettlementDataRoom, SettlementBoard, BranchSettlementStatement, InterOfficeSettlement, SettlementAcknowledgement, and SettlementAdjustmentLine. Acceptance proof: Danbee, branch-to-HQ, HQ, inter-office, coupon-fee split, manual ETC rows, completion state, and repair history are separate workflow facts.
Caregiver payroll, grade, and multi-caregiver contracts are separate facts. Status: Partial. Evidence: source-refs/sanmopia-admin/application/models/Reservation_model.php:38-42, source-refs/sanmopia-admin/application/models/Reservation_model.php:2245-2293, source-refs/sanmopia-admin/application/models/Reservation_model.php:2471-2561, source-refs/sanmopia-admin/application/models/Manager_model.php:399-475, source-refs/sanmopia-admin/application/models/Manager_model.php:716-725, source-refs/sanmopia-admin/application/controllers/Manager.php:1133-1178, and source-refs/sanmopia-admin/application/controllers/Manager.php:1847-1883. Required vocabulary: CaregiverAssignmentContract, CareTeamMemberRole, CaregiverAssignmentChangeLog, CaregiverGradeSnapshot, CaregiverCompensationQuote, SubCaregiverPayoutLedger, and TaxWithholdingMode. Acceptance proof: ordered assistant caregivers, replacement logs, grade snapshots, main/sub payout ledgers, custom pay, tax mode, and receipt status no longer share mutable PHP rows.
UI-side financial and payroll calculations must be diagnostics only. Status: Partial. Evidence: source-refs/sanmopia_web/static/js/step3.js:24-44, source-refs/sanmopia_web/static/js/step3.js:132-149, source-refs/sanmopia_web/static/js/step3.js:199-327, source-refs/sanmopia_web/static/js/step3.js:345-383, source-refs/sanmopia_web/static/js/step3.js:477-556, source-refs/sanmopia-admin/static/js/reservation_status/reservation_add.js:1991-2145, and source-refs/sanmopia-admin/static/js/manager/manager_pay_detail.js:155-231. Required vocabulary: ReservationQuoteSnapshot, ChargeLineProjection, ServiceCalendarQuoteImpact, BackendOnlyCompensationQuote, and PaymentAmountAuthorization. Acceptance proof: rental, delivery, service discounts, voucher surcharges, Saturday/holiday rows, selected dates, payroll tax, and compensation totals are backend snapshots with policy versions.
Old-Astro and portal UI decision clones are backend projections. Status: Partial. Focused page: Legacy UI Business Logic Gap Mining. Evidence: source-refs/sanmopia-user-old/src/design-system/ui-kit/templates/TemplateReservationList.astro:26-29, source-refs/sanmopia-user-old/src/design-system/ui-kit/islands/ReservationTabIsland.tsx:57-80, source-refs/sanmopia-user-old/src/design-system/ui-kit/organisms/ReservationPaymentInfo.astro:22-80, source-refs/sanmopia-user-old/src/design-system/ui-kit/molecules/ReceiptButtonGroup.astro:22-89, source-refs/sanmopia-user-old/src/design-system/ui-kit/molecules/DocumentList.astro:23-46, source-refs/sanmopia-user-old/src/design-system/ui-kit/templates/TemplateDailySubReport.astro:22-31, source-refs/sanmopia-manager/application/views/schedule/schedule_info.php:136-203, source-refs/sanmopia_web/static/js/menu/feeguide.js:1-144, and source-refs/sanmopia-admin/static/js/manage_system/holiday_list.js:18-106. Required vocabulary: CustomerReservationListBucketProjection, CustomerPaymentActionProjection, CustomerReceiptAccessProjection, CustomerDocumentAvailabilityProjection, CustomerReportObligationProjection, CareManagerServiceBalanceAcknowledgementProjection, PublicFeeGuideCatalogProjection, and HolidayPolicyCommandProjection. Acceptance proof: customer/caregiver/admin UI renders backend projections with revision, policy/catalog version, disabled/missing reasons, and command target metadata; source status ids, Korean payment labels, numeric document ids, browser current-date checks, 마지막날 string matching, Saturday/holiday total math, fee-guide filename conventions, and modal data-type command selection remain adapter evidence only.

2026-07-05 CaveCrew Migration Refresh

Read-only CaveCrew mining refreshed backend-owned migration obligations while the main track implemented the refund command contract. These are acceptance slices, not source code to copy.

Payment product authority still needs gift-coupon offers, added service day pricing, voucher basis, benefit over-credit, and operator correction rows converged into versioned product/catalog facts. Status: Partial. Evidence: source-refs/sanmopia_web/application/controllers/api/Payment.php:65-735, source-refs/sanmopia-admin/application/models/Payment_model.php:101-230, and gift-coupon list/action pages.
Cancellation refund side effects must become one backend saga. Status: Partial. Evidence: source-refs/sanmopia_web/application/models/Reservation_model.php:989-1065, source-refs/sanmopia_web/application/models/Payment_model.php:383-440, and source-refs/sanmopia-admin/application/libraries/Kcppayment.php:447-456. Required proof: provider success, paid/refunded state, coupon/benefit restore, Momfirst unlink, outbox ordering, and settlement reversal are linked to the reservation operation workflow, not triggered from controller branches. Backend now splits refund closeout from payment_refund_completion_barrier so downstream entitlement and settlement work cannot complete before terminal provider refund evidence or zero-refund facts exist. Remaining work: wire real provider-event ingestion, zero-refund persistence, and worker execution.
Danbee, branch, headquarters, and inter-office settlement exports need separate statement/read models. Status: Partial. Evidence: source-refs/sanmopia-admin/application/controllers/Calculate.php:150-578, source-refs/sanmopia-admin/application/models/Payment_model.php:828-980, source-refs/sanmopia-admin/application/models/Payment_model.php:2977-3052, and source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3741-3805. Required proof: manual/negative/component paid lines, dataset revision, export lineage, branch/HQ visibility, and acknowledgement state are typed facts, not recomputed spreadsheet rows.
Caregiver payroll must stop read-time salary recomputation. Status: Backend-backed foundation. Evidence: source-refs/sanmopia-manager/application/helpers/salary_helper.php:8-227, source-refs/sanmopia-admin/application/models/Reservation_manager_salary_model.php:21-52, and manager salary/detail models. Backend now freezes versioned payout policy profile, care-team slot identity, extension/repeating option amounts, voucher add-on/tax cutover, custom service balance, primary/assistant custom pay, override source, payout instruction, receipt state, adjustment audit, and destination-change audit. Remaining proof: Supabase decision snapshot persistence and admin/manager/HQ screen binding.
Subsidy, regional duration benefit, and branch coverage decisions must use effective-dated profiles. Status: Partial. Evidence: source-refs/sanmopia_web/static/js/step3.js:281-293, source-refs/sanmopia-admin/static/js/reservation_status/reservation_add.js:927-945, and reservation model regional-support branches. Required proof: Wanju-style added days, Yeongdeungpo-style address conditions, payment conversion impact, and settlement impact are profile rows and frozen booking evidence, not hardcoded region names.
Reservation state transitions need complete follow-up binding. Status: Partial. Evidence: source-refs/sanmopia-admin/application/config/constants.php:116-137 and cancellation/stop/change controller branches. Required proof: customer change/cancel/stop requests, broad operator edits, cron/payment callbacks, transition ledger persistence, stale-save conflict handling, and generated clients all consume ReservationLifecycleSideEffectPlan.

2026-07-03 Admin UI Decision Delta

Focused scan: source-refs/sanmopia-admin PHP and JavaScript where browser or controller code calculates money, chooses workflow state, or selects operational roles. These are migration obligations, not frontend behavior to preserve.

Admin reservation intake service plan, regional benefit, and charge freeze. Status: Partial. Evidence: source-refs/sanmopia-admin/static/js/reservation_status/reservation_add.js:927-948, source-refs/sanmopia-admin/static/js/reservation_status/reservation_add.js:1200-1542, source-refs/sanmopia-admin/static/js/reservation_status/reservation_add.js:1883-2124, source-refs/sanmopia-admin/static/js/reservation_status/reservation_add.js:2155-2204, source-refs/sanmopia-admin/application/controllers/Reservation.php:1324-1349, source-refs/sanmopia-admin/application/controllers/Reservation.php:1739-1758, source-refs/sanmopia-admin/application/models/Reservation_model.php:4093-4139, source-refs/sanmopia-admin/application/models/Reservation_model.php:4153-4181, and source-refs/sanmopia-admin/application/models/Payment_model.php:3748-3825. Required proof: reservation_operations / ReservationAdminIntakeCommand, ReservationServiceCalendarPlan(service_days_per_week), ReservationExtraServiceSelection, pricing_settlement / RegionalBenefitDecision, CustomerSharePaymentSchedulePolicy, and ReservationChargeFreeze own address-scoped benefit eligibility, service-period math, added Saturday/holiday dates, regional extra days, add-on quantity pricing, voucher deposit/balance split, zero-amount closeout, and charge freeze. UI must render backend decisions only; it must not decide benefit visibility from address strings, multiply add-on prices by client-side service period, or split customer charges from source status and version flags.
Admin payment conversion board amount and status decisions. Status: Partial. Evidence: source-refs/sanmopia-admin/application/views/table/reservation_status/table_payment_change.php:5-14, source-refs/sanmopia-admin/static/js/reservation_status/payment_change.js:1-180, source-refs/sanmopia-admin/application/controllers/ajax/Reservation.php:68-178, and source-refs/sanmopia-admin/application/models/Payment_model.php:4422-4521. Required proof: pricing_settlement / PaymentChangeOperatorBoard, PaymentChangeAmountBreakdown, PaymentChangeOperatorCommand, PaymentChangeCompletionAudit, and PaymentChangeProjectionInvalidation freeze requested amount, current reservation charge basis, prior payment timestamps, allowed operator transitions, synthetic cancellation display, completion timestamp, and audit. UI must not recompute payable amount from current reservation/coupon rows, synthesize a cancellation status id, or overwrite amount/status by raw row id.
Branch/headquarters settlement line selection, fee arithmetic, and download handoff. Status: Partial. Evidence: source-refs/sanmopia-admin/static/js/calculate_detail.js:20-225, source-refs/sanmopia-admin/static/js/calculate_detail.js:240-337, source-refs/sanmopia-admin/static/js/calculate_detail.js:342-380, source-refs/sanmopia-admin/static/js/calculate_detail.js:417-533, source-refs/sanmopia-admin/static/js/calculate_detail.js:609-900, and source-refs/sanmopia-admin/static/js/calculate_detail.js:939-1144. Required proof: pricing_settlement / SettlementStatementCommandContext, SettlementLineAcknowledgement, SettlementManualAdjustmentPolicy, SettlementCompletionReview, SettlementArtifactRequest, SettlementArtifactGrant, and DownloadHandoffAudit own selected line membership, actor-specific command route, payment-method fee policy, membership due, delivery fee, gift-coupon commission, manual rows, completion counters, signed download, and replay/repair audit. UI must not submit a mixed FormData blob of checked rows and client totals, calculate payment fees in JavaScript, choose completion flags from raw status ids, or download artifacts through raw query-string redirects.
Caregiver candidate snapshot and care-team role assignment. Status: Partial. Evidence: source-refs/sanmopia-admin/application/views/reservation_status/reservation_detail.php:900-1144, source-refs/sanmopia-admin/static/js/reservation_status/reservation_detail.js:500-629, source-refs/sanmopia-admin/static/js/reservation_status/reservation_detail.js:660-740, source-refs/sanmopia-admin/application/models/Matching_model.php:44-177, and source-refs/sanmopia-admin/application/models/Matching_model.php:724-862. Required proof: caregiver_assignment / CaregiverCandidateSnapshot, CaregiverAssignmentDecision, CaregiverAssignmentConflict, CaregiverTransportEvidence, and CareTeamContract persist ranking policy, score components, branch scope, pet exclusion, schedule proof, deterministic tie-breaker, distance, transport provider result, selected role slot, duplicate/conflict result, actor, reason, and replacement impact. UI must not treat highlighted candidate cards, hidden input role slots, or browser-only duplicate checks as the final assignment decision.
Caregiver payout amount, tax election, and receipt state. Status: Partial. Evidence: source-refs/sanmopia-admin/application/views/manager/manager_pay_detail.php:101-115, source-refs/sanmopia-admin/application/views/manager/manager_pay_detail.php:462-644, source-refs/sanmopia-admin/static/js/manager/manager_pay_detail.js:1-260, source-refs/sanmopia-admin/static/js/manager/manager_pay_inquiry.js:80-286, source-refs/sanmopia-admin/application/controllers/Manager.php:986-1335, source-refs/sanmopia-admin/application/models/Reservation_model.php:2453-2625, source-refs/sanmopia-admin/application/models/Reservation_model.php:2627-2935, source-refs/sanmopia-admin/application/models/Reservation_model.php:2945-3041, source-refs/sanmopia-admin/application/models/Reservation_manager_salary_model.php:21-52, source-refs/sanmopia-admin/application/models/Reservation_manager_salary_model.php:112-180, and source-refs/sanmopia-admin/application/config/constants.php:272-274. Required proof: pricing_settlement / CaregiverCompensationQuote, CaregiverPayoutInstruction, CaregiverTaxElection, CaregiverPayoutAdjustmentAudit, CaregiverPayoutAcknowledgement, and ReservationCompletionDecision own gross/net quote, add-on basis, override amount, reset behavior, tax policy, memo, main/assistant payout status, receipt timestamp, service-balance acknowledgement, reservation completion side effect, expected revision, actor, and reason. UI must not recompute tax and final pay, post an editable amount as the payout source of truth, or mark reservation completion as an incidental payout-screen side effect. 2026-07-04 contract progress: public TS contracts now expose CaregiverPayoutAcknowledgementCommand and CaregiverPayoutAcknowledgementReadModel with branch deposit state, caregiver receipt state, actor, expected revision, idempotency key, and replay guard. Backend already has the corresponding caregiver payout acknowledgement domain/application/Supabase slice. Supabase now persists receipt-state events and current projections separately, so idempotent replay, revision conflict evidence, and manager-facing read state do not depend on mutable salary UI rows. 2026-07-04 follow-up: FastAPI now exposes branch deposit acknowledgement plus caregiver receipt acknowledgement, exception, repair, and read-state routes; the API derives the actor from Supabase Auth and checks SpiceDB record_caregiver_payout or caregiver self-view permission before saving commands. Public TS/OpenAPI contracts now expose those paths, request/response schemas, receipt-state command kinds, and Supabase receipt event/projection table rows. 2026-07-04 adjustment follow-up: backend now records CaregiverPayoutAdjustmentAudit as an append-only command with Supabase actor derivation, SpiceDB record_caregiver_payout permission, idempotency replay guard, target-level expected revision, and full previous/adjusted payable amount, withholding, tax category, and memo snapshots. Supabase persists sanmopia_caregiver_payout_adjustment_audits with participant RLS, service role upsert grants, realtime publication, and target revision indexes. Public TS/OpenAPI contracts expose /caregiver-payout-adjustment-audits, request and response schemas, changed-field vocabulary, and Supabase row types. Remaining follow-up: backend now records CaregiverPayoutDestinationChangeAudit as an append-only command with Supabase actor derivation, SpiceDB record_caregiver_payout permission, idempotency replay guard, target-level expected revision, full previous/adjusted bank-account and tax-evidence snapshots, changed-field vocabulary, participant RLS, service-role upsert grants, realtime publication, FastAPI route /caregiver-payout-destination-change-audits, public TS/OpenAPI schemas, and Supabase row types. Branch-deposit acknowledgement now matches backend payout-slot identity with caregiver role and handoff order for source SORT > 0 assistant rows. 2026-07-07 backend follow-up: backend commit 81719dc adds AdminCaregiverPayoutStatementProjection, CaregiverPayoutSlot, CaregiverPayoutOperatorActionAvailability, CaregiverPayoutServiceBalanceState, and CaregiverPayoutCompletionDecision. The application contract now exposes BuildAdminCaregiverPayoutStatementProjectionResult so admin/manager screens can render frozen gross/net/tax/service-balance/deposit/receipt/completion state without PHP/JS salary recalculation. Extra evidence: source-refs/sanmopia-admin/application/views/manager/manager_pay_detail.php:4-115, :575-644, source-refs/sanmopia-admin/static/js/manager/manager_pay_detail.js:14-24, :75-86, :155-231, source-refs/sanmopia-admin/static/js/manager/manager_pay_inquiry.js:183-231, source-refs/sanmopia-admin/application/models/Manager_model.php:332-516, source-refs/sanmopia-admin/application/controllers/Manager.php:1133-1236, source-refs/sanmopia-admin/application/models/Reservation_model.php:2627-2775, :2945-3041, and source-refs/sanmopia-admin/application/config/constants.php:272-274. 2026-07-07 persistence follow-up: backend commit 292f736 adds Supabase-backed admin payout statement projection and row tables, participant RLS, realtime publication, deterministic projection/row ids, latest-revision reader, row upsert store, and JSONB display/action roundtrip for multiple caregiver slots on one contract. It also tightens reservation-history export RLS with an explicit signed-in guard and promotes optional integer/datetime and text-array row readers into SupabaseRow instead of adding feature-local coercion code. Remaining proof: FastAPI route, generated TS/OpenAPI binding, projection refresh trigger from payout-statement changes, and portal removal of UI-side payout completion logic.

2026-07-03 Notification And Document Delivery Delta

Focused page: Notification And Document Delivery Gap Mining.

Legacy source path/evidence	Modern bounded context / feature name	Implementation status	Migration priority	Notes
`source-refs/sanmopia_web/application/controllers/api/Reservation.php:115-227`, `source-refs/sanmopia_web/static/js/mypage/reservation.js:337-421`, `source-refs/sanmopia_web/application/controllers/api/Menu.php:26-72`, `source-refs/sanmopia-admin/application/controllers/Member.php:410-446`, `source-refs/sanmopia-admin/application/models/Faq_model.php:65-84`, `source-refs/sanmopia-admin/static/js/member/faq_detail.js:22-67`	`reservation_orchestration / CustomerReservationRequestIntent`, `customer_engagement / CustomerInquirySubmissionIntent`, `CustomerInquiryAnswerIntent`, `CommunicationDispatchRequest`, `BranchNotificationRoutingPolicy`	Partial	P0	Customer request and inquiry paths still mutate request/inquiry state, choose recipients, send provider messages, send customer push, and let browser callbacks choose customer-visible completion copy inline. Backend/contract foundation now freezes customer cancel/stop/change intake as `CustomerReservationRequestIntentPlan`: it requires expected reservation revision, profile-driven `branchRoutingProfileKey`, branch recipient facts, backend-owned dispatch idempotency keys, provider-neutral workflow instructions, and backend message keys such as `reservation_request.cancellation.completed`. Customer inquiry submission now has a separate `CustomerInquirySubmissionIntentPlan` in `customer_engagement`: it freezes inquiry persistence, submission idempotency, branch routing profile, branch recipient facts, provider-neutral dispatches, backend result route/message keys, and excludes `questionBody` from provider notification payloads so full inquiry text stays in persisted inquiry records. Customer inquiry answer now has `CustomerInquiryAnswerIntentPlan`: it replaces legacy branch `isMyFaq` checks and `FAQ_ANSWERED` insertion with branch-profile equality guards, expected inquiry revision, idempotent answer mutation facts, backend result route/message keys, and a `customer_inquiry:answered_mother` Novu workflow whose notification payload excludes `answerBody`. OSS workflow catalog/Supabase seed covers cancellation requested/completed, care-stop requested, change requested, customer-inquiry submitted, and customer-inquiry answered triggers without source branch-id or FAQ constants in new contracts. Remaining migration: persist intent plans, bind authenticated API commands and conflict handling, enqueue dispatch requests/events, wire customer/operator result projections, and remove UI callback text/recipient branching.
`source-refs/sanmopia_web/application/controllers/api/Payment.php:421-463`, `source-refs/sanmopia_web/application/controllers/api/Payment.php:439-491`, `source-refs/sanmopia_web/application/controllers/api/Payment.php:598-643`, `source-refs/sanmopia_web/application/controllers/api/Payment.php:740-754`, `source-refs/sanmopia_web/application/controllers/api/Kcp.php:75-100`, `source-refs/sanmopia_web/application/models/Payment_model.php:353-380`, `source-refs/sanmopia_web/application/models/Payment_model.php:531-567`, `source-refs/sanmopia_web/application/models/Payment_model.php:654-677`, `source-refs/sanmopia_web/application/models/Payment_model.php:708-716`	`pricing_settlement / CustomerPaymentInstruction`, `PaymentVirtualAccountInstructionPayload`, `VirtualAccountPaymentLifecycle`, `PaymentCommunicationWorkflow`, `customer_engagement / CommunicationDispatchRequest`	Partial	P0	Payment controller still builds virtual-account and completion messages, selects provider template/fallback, sends branch/customer notices, and special-cases extra recipients. Backend must freeze purpose, amount, method, provider route, visible message state, recipient policy, idempotency, retry, and audit before provider handoff. Virtual-account issue notice, waiting-payment row, and deposit callback must share one frozen request amount. 2026-07-05 backend follow-up: `KillBillPaymentEventIngestionHandler` extracts provider paid amount candidates (`amountKrw`, `amount`, `paidAmount`, `ipgm_mnyx`, `good_mny`) from raw webhook payloads and rejects mismatches before starting `ReservationPaymentWorkflow`, so callback amount drift cannot mark paid or trigger settlement. Remaining proof: persist provider-approved amount snapshots for receipt artifacts and bind every issued-VA notice to the same frozen request.
`source-refs/sanmopia_web/application/views/mypage/reservation_document.php:45-123`, `source-refs/sanmopia-admin/application/controllers/cli/ReservationDocument.php:19-129`, `source-refs/sanmopia-admin/application/controllers/cli/ReservationDocument.php:158-225`, `source-refs/sanmopia_web/application/controllers/Notification.php:19-27`	`document_reporting / ReservationDocumentCatalog`, `ReservationDocumentBundle`, `DocumentAccessGrant`, `DocumentDeliveryAttempt`	Partial	P0	Customer view still chooses numeric document ids and token URLs. Backend/domain and TS/JSON contracts now require reservation/document/artifact/channel/action scoped access grants: grant history carries `documentDefinitionKey`, `documentArtifactVersionKey`, `accessChannel`, and `allowedActionCodes`, and delivery validation rejects grants that do not match the delivery document or channel. Scheduled CLI still chooses file lists from service/payment/status facts, sends email attachments, records send status, and deletes temp files. Remaining migration: Supabase persistence, signed-storage issuing route, scheduled/manual worker binding, resend/revoke operator UX, and full source attachment/template parity.
`source-refs/sanmopia_web/application/views/mypage/item/reservation_func_btn.php:1-190`, `source-refs/sanmopia_web/application/views/mypage/item/reservation_detail_func_btn.php:1-210`, `source-refs/sanmopia_web/application/views/mypage/pre_reservation_detail.php:41-90`, `source-refs/sanmopia_web/application/views/mypage/reservation_detail.php:421-452`, `source-refs/sanmopia_web/static/js/mypage/reservation.js:337-421`	`reservation_operations / CustomerActionAvailabilityPolicy`, `CustomerReservationStateMappingCatalog`, `CustomerReservationStateSnapshot`, `CustomerNewReservationEligibilityPolicy`, `CustomerReservationLifecycleSnapshot`, `CustomerActionCommand`	Partial	P0	Customer pages still choose payment, delivery, report, cancel, continue, reschedule, conversion, and more-info actions from raw status/payment maps; browser code chooses route and success copy after response. Backend foundation now owns policy-rule evaluation, disabled reasons, command target, descriptor message keys, idempotency scope, service-end gates, change/stop request actions, service-balance instruction readiness, and a versioned source-status mapping catalog so old reservations can project `source_status_code` plus catalog version into current customer lifecycle language, `customer_list_bucket`, `detail_surface_kind`, and `blocks_new_reservation` without frontend status switches. `CustomerDetailSurfaceKind` is now shared vocabulary used by state snapshot and lifecycle snapshot: `15/16` select pre-reservation detail directly, while `9/17/19` need `pre_reservation_flag=true` and `pre_conversion_completed=false`. `CustomerNewReservationEligibilityPolicy` now composes projected reservations and returns `available` or `blocked_by_existing_reservation` with blocker reservation ids, so the frontend does not inspect source status `8/14/16` directly. Remaining migration must persist mapping/policy catalogs, wire API/read adapters, bind actor authorization, and remove raw status branches from portal UI.
`source-refs/sanmopia_web/application/controllers/api/Shop.php:105-166`, `source-refs/sanmopia_web/application/controllers/management/Push.php:10-45`, `source-refs/sanmopia_web/application/controllers/management/Push.php:49-86`, `source-refs/sanmopia_web/application/models/Notification_model.php:16-68`	`customer_engagement / PromotionDeliveryAttempt`, `CampaignDispatchSegment`, `NotificationInboxItem`, `CommunicationDispatchRequest`	Partial	P1	Customer-engagement paths still resend gift-coupon SMS, manually segment campaign push recipients by raw reservation status/token rows, and insert inbox rows from device tokens. Backend must own audience policy, recipient snapshots, inbox action projections, dispatch attempts, provider results, suppression reasons, and repairable retries.
`source-refs/sanmopia_web/application/controllers/Momfirst.php:87-145`, `source-refs/sanmopia_web/application/controllers/Clean.php:67-125`	`customer_engagement / PartnerBenefitResultArtifact`, `DocumentAccessGrant`, `PartnerBenefitDeliveryBatch`	Partial	P1	Partner-result downloads still validate document tokens, check reservation ownership, read admin-root file paths, and stream bytes directly. Backend must expose storage-backed result artifacts with grant expiry, checksum/content metadata, provider delivery batch state, and access audit.

Status compatibility facts found during the customer-action migration: reservation status codes are duplicated across web/admin/manager constants and runtime DB maps, including 0 예약, 1 상담, 2 일정미확정, 3 확정, 4 진행, 5 정산, 6 완료, 7 변경요청, 8 취소요청, 9 취소, 10 연장요청, 11 연장, 12 중단요청, 13 중단, 14 입금대기, 15 사전예약, 16 사전예약대기, 17 입금대기취소, 18 사전예약취소, and 19 오프라인. Customer tabs and actions are split across MyReservation.php:21-90, reservation_func_btn.php:1-190, reservation_detail_func_btn.php:1-210, reservation.js:326-560, and cron transitions in cli/Reservation.php:12-70. Modern code must keep those numeric source codes in status-mapping catalogs such as legacy_web:17, not in UI conditions or action-policy branches. Additional tab and blocking facts: MyReservation active bucket is 0,1,2,3,4,5,7,8,10,11,12,14,15,16; history bucket is 6,9,13,17; customer tabs omit -1, 18, and offline 19. New reservation is blocked only by existing 8 취소요청, 14 입금대기, and 16 사전예약대기; source draft -1 작성중 is deleted/replaced on insert. 19 오프라인 remains an admin-side projection/status dimension and must not silently enable customer actions. Pre-reservation admin detail has a different status surface from customer tabs: pre_reservation_detail.php:90-118 exposes source statuses 9, 15, 16, 17, and 19, while 18 사전예약취소 remains defined in constants but is not selectable there. Needs source confirmation: treat 18 as either legacy-data compatibility or a separate command result only after checking production rows or DB seed values; do not alias it to 9 in new contracts without evidence.

2026-07-03 Sidecar Feature Gap Delta

Focused scan: legacy admin, manager, and customer PHP/JavaScript paths that were not yet named as feature slices in this checklist. These entries are modernization obligations only; legacy code shape must not be copied.

Legacy source path/evidence	Modern bounded context / feature name	Implementation status	Migration priority	Notes
`source-refs/sanmopia_web/application/models/Reservation_model.php:264-306`, `source-refs/sanmopia_web/application/controllers/api/Reservation.php:363-405`, `source-refs/sanmopia-admin/application/controllers/Reservation.php:699-897`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:6016-6032`, `source-refs/sanmopia-manager/application/views/schedule/schedule_info.php:557-562`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3558-3562`	`reservation_operations / PostpartumCareCenterStayPlan`, `ServiceDueDatePolicy`, `ReservationDeliveryProfile`	Partial	P0	Backend foundation migrated under `reservation_operations/features/postpartum_care_center_stay`: versioned stay-plan catalog, delivery-method due-date rules, customer/operator command actor roles, expected revision, continuation next-weekday policy, service due-date recalculation, service-calendar/matching/pricing/payment/document invalidation targets, caregiver schedule fields, and document projection are now backend-owned. Remaining migration must persist stay-plan catalogs/profile revisions in Supabase, expose command/query APIs, bind mother/branch/HQ authorization, and wire UI without source care-center ids or UI date recomputation.
`source-refs/sanmopia-admin/application/controllers/Reservation.php:1490-1518`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:6100-6113`, `source-refs/sanmopia-admin/application/controllers/Reservation.php:452`, `source-refs/sanmopia-admin/application/controllers/Reservation.php:632-640`	`reservation_operations / OfflineReservationIntakeCommand`, `ReservationDuplicateGuard`, `ManualReservationSource`	Partial	P1	Backend foundation migrated under `reservation_operations/features/offline_reservation_intake`: deterministic idempotency keys, normalized customer identity, service-period overlap checks, actor/source channel, branch scope, duplicate decision audit, and explicit conflict response are now domain/application-owned instead of source status-id queries or browser retry messages. Supabase now persists backend-owned `sanmopia_offline_reservation_duplicate_decision_audits` rows with idempotency key, branch/customer/service-period query columns, accepted/conflict decision, reason code, existing reservation evidence, and immutable Pydantic decision snapshot. Remaining migration must expose the API command handler, bind actor authorization, and wire operator UI.
`source-refs/sanmopia-admin/application/controllers/Calculate.php:504-548`, `source-refs/sanmopia-admin/application/models/Service_model.php:274-319`, `source-refs/sanmopia-admin/static/js/calculate/other_service_management.js:1-89`, `source-refs/sanmopia-admin/application/views/calculate_detail.php:1214-1265`	`pricing_settlement / SettlementManualAdjustmentCatalog`, `SettlementManualAdjustmentCatalogVersion`, `SettlementManualAdjustmentLine`	Partial	P1	Backend foundation migrated under `pricing_settlement/features/settlement/manual_adjustment_catalog.py`: source `LIST_SERVICE_ETC_TB` add/edit/delete is now a stable-code, revision-guarded, versioned manual-adjustment catalog; used entries deprecate instead of hard-deleting; catalog mutations require headquarters actor/reason/idempotency audit; opened branch, Danbee, and inter-office statement lines freeze catalog version, display name, unit price, quantity, direction, actor, statement revision, lineage evidence, and total amount in backend-owned snapshots so later catalog edits cannot rewrite totals. Branch-scope frozen lines now project to bidirectional `branch_adjustment` line items, so receivable/payable manual extra rows enter backend net-balance math instead of UI/view `PRICE * COUNT`. This removes source numeric row ids from contracts, UI-rendered-row edit state, and client/view authority. Remaining migration must persist catalog versions/usage snapshots/frozen lines in Supabase, expose command/query routes, bind SpiceDB/RLS, and wire operator UI.
`source-refs/sanmopia-admin/application/config/constants.php:291-313`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:646-923`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:2453-2535`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:2568-2625`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:3095-3148`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:3507-3555`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:3560-3642`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:3667-3685`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:5608-5867`, `source-refs/sanmopia-admin/application/controllers/Reservation.php:461-511`, `source-refs/sanmopia-admin/application/controllers/Reservation.php:1819-1855`, `source-refs/sanmopia-admin/application/controllers/Manager.php:980-1135`, `source-refs/sanmopia-admin/application/views/reservation_status/reservation_price_table.php:1-120`, `source-refs/sanmopia-admin/static/js/reservation_status/reservation_detail.js:390-410`, `source-refs/sanmopia-admin/static/js/reservation_status/reservation_detail.js:760-832`, `source-refs/sanmopia-admin/static/js/reservation_status/reservation_detail.js:1031-1068`	`pricing_settlement / ReservationPriceVersionAndSubsidyAdjustment`, `PriceCatalogVersionPolicy`, `ReservationServiceBalanceOverride`, `VoucherPureAdditionalServiceBalance`, `ReservationServiceBalanceConfirmation`, `ServiceBalancePaymentCloseout`, `CaregiverServiceBalanceReceiptCloseout`	Partial	P1	Backend foundation migrated under `pricing_settlement/features/reservation_price_version_adjustment`, `pricing_settlement/features/pricing/voucher_service_add_on.py`, `pricing_settlement/features/settlement/service_balance.py`, and `pricing_settlement/features/payment/reservation_service_balance_closeout.py`: `PRICE_VERSION_YEAR` is now dated catalog-version policy, price-version apply produces immutable before/after facts instead of mutating reservation/payment/add-option rows, voucher consume-type service-day mismatch becomes a blocked decision, subsidy/regional-support/customer-share deltas are backend facts, branch service-balance override freezes default/override amounts with actor/reason/idempotency audit, voucher pure-additional service balance subtracts frozen special/live-in voucher add-on amount from posted service-balance amount, service-balance confirmation freezes the actual `/reservation/confirmServiceBalance` closeout effect as `SERVICE_BALANCE_PRICE`, `SERVICE_BALANCE_CONFIRM_FL = 1`, and `SERVICE_BALANCE_PRICE_USE_FL = 1` decision metadata, and service-balance payment closeout now models source branch-manager `서비스잔금` row creation plus zero-amount auto-completion as backend-owned receipt states for any number of caregiver recipients. This removes numeric price-version ids from contracts, source UI year-label hardcoding, controller row rewrite authority, UI-entered service-balance totals, confirm-only stale endpoint behavior, fixed primary/sub-only receipt modeling, and DOM-mutated add-service totals as source of truth. Service-balance closeout now has service-role Supabase RPC persistence, RLS read policies, a backend API route, and backend commit `4e4b140` requires frozen `finalizedChargeSnapshotId`, `serviceOccurrenceLedgerKey`, and `serviceOccurrenceLedgerRevisionNumber` on the closeout command/API/HTTP/RPC path before receipt states can be opened. Focused 2026-07-07 proof includes service-balance closeout tests, reservation smoke, HTTP booking workflow-start tests, stage Supabase migration replay, stage schema lint, regenerated Supabase types, and `supabase:smoke:stage:service-balance-closeout` rollback smoke. Remaining migration must persist voucher pure-additional decisions and non-closeout adjustment audits, bind SpiceDB/RLS for the remaining commands, connect price catalog read models, expose price-table and service-balance projection APIs, and wire operator UI without client-side recalculation.
`source-refs/sanmopia-admin/application/controllers/cli/ReservationDocument.php:254-621`, `source-refs/sanmopia-admin/application/controllers/ajax/DataRoom.php:76-78`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:4323-4383`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:4388-4459`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:6117-6127`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4104-4113`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4328-4338`, `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4486-4488`	`document_reporting / VoucherEndNoticeReadiness`, `VoucherEndNoticeReadinessParity`, `VoucherEndNoticeDeliveryBatchReadinessDecision`, `VoucherEndNoticeDeliveryAttempt`, `DocumentArtifactReadiness`	Partial	P0	Backend foundation expanded in `document_delivery`: voucher end notice readiness now owns normal/stopped batch kind, voucher eligibility, reservation-status skip, customer-deposit payment confirmation, artifact readiness, signed grant state, sent-attempt duplicate suppression, failed-attempt retry planning, and customer inbox action payloads. Source still gates the same document differently across DataRoom user-level `END_DOCUMENT` filtering, notification `DATA` search by reservation id, bulk/admin silent skip, customer PDF error handling, scheduled mail batch selection, always-rendered mail PDF type `21`, and mail audit flags `3`/`4`. One backend readiness decision must bind reservation id, user id, notification/grant evidence, artifact readiness, missing reason, batch kind `normal_end` versus `stopped_end`, payment prerequisite, skip-status reason, duplicate suppression, notification/action creation, manual download, bulk bundle, scheduled mail render, resend, and access grant. This replaces source doc id `21`, mail flags `3/4`, `END_DOCUMENT` notification text search, and hardcoded `/myReservation/document/{id}` contract leakage. Remaining migration must persist readiness/grant/action history in Supabase, bind render worker/provider handoff, expose routes, add resend/revoke controls, wire access-history UI, and prove cross-entrypoint readiness parity.

2026-07-05 source-dig addition for ReservationServiceBalanceOverride: /reservation/serviceBalanceConfirm is stale JavaScript with no verified CodeIgniter route alias. Actual reachable path is /reservation/confirmServiceBalance, which sets SERVICE_BALANCE_PRICE, SERVICE_BALANCE_CONFIRM_FL = 1, and SERVICE_BALANCE_PRICE_USE_FL = 1. The similarly named model method only flips SERVICE_BALANCE_CONFIRM_FL. Modern closeout commands must preserve the actual three-field effect and keep stale endpoint naming as adapter-only migration evidence. Backend now has ConfirmReservationServiceBalance / ConfirmReservationServiceBalancePayload foundation for the actual three-field closeout; remaining work is Supabase persistence, command API, payment-row closeout, and receipt/settlement side-effect binding. 2026-07-05 backend follow-up: ServiceBalancePaymentCloseout, CaregiverServiceBalanceReceiptCloseout, and CloseReservationServiceBalanceHandler now cover source insertServiceBalanceInfo: create a service-balance receivable, keep positive amounts waiting for branch payment and caregiver receipt confirmation, and auto-complete all caregiver receipt states when the service balance is zero. Supabase now persists this as an idempotent closeout event/current row plus caregiver receipt-state rows through sanmopia_save_service_balance_closeout, and the backend exposes POST /reservation-service-balance-closeouts. Backend commit 4e4b140 now requires the closeout request to include the finalized charge snapshot id and the service occurrence ledger key/revision, persists those frozen references in the Supabase closeout event/current row, and rejects idempotency reuse when those references drift. Focused proof on 2026-07-07 includes reservation smoke, HTTP booking workflow-start tests, and supabase:smoke:stage:service-balance-closeout, which proves the stage DB booking RPC -> occurrence ledger -> closeout RPC path inside a rolled-back transaction. Follow-up proof supabase:smoke:stage:financial-lifecycle-closeout-guard now creates a real stage booking, reuses the booking-created occurrence ledger instead of inserting a duplicate revision, records service delivery and caregiver payout, rejects stale serviceBalanceCloseoutEventId at Branch settlement, then accepts the backend-confirmed Branch/HQ settlement references through settled. The live proof exposed and fixed a schema drift bug: additional-service selection revision reads must derive paths from journal field_changes, not the broadcast-only changed_field_paths label. 2026-07-08 source-dig addition: the reachable service-balance override path also records actor office facts as JSON plus the posted override amount in RESERVATION_SERVICE_CUSTOM_LOG_TB before applying the current balance (source-refs/sanmopia-admin/application/controllers/Reservation.php:461-511, source-refs/sanmopia-admin/application/models/Reservation_model.php:5904-5912). Modern ReservationServiceBalanceOverrideAuditLedger must make actor office, command source, previous/default amount, posted amount, derived voucher-pure additional amount, expected charge revision, and idempotency key first-class; UI-submitted balance and JSON branch labels are request evidence only. Remaining work: operator conflict/audit binding, branch/HQ repair UX, settlement-completion side-effect execution, frontend wiring, and full E2E proof through the running app container.
2026-07-05 source-dig addition for hidden PHP/UI business logic: ServiceTermCalendarPolicy, ReservationAddDayCommand, ProductCouponEntitlementSchedule, CustomerChargeRecomposition, VoucherServiceAdditionalPriceAdjustment, PreReservationCouponOverpayFulfillment, SettlementLineKindBook, CareTeamRoleContract, TravelEvidenceProvider, BranchCoverageDecision, RegionalBenefitRule, and DocumentSeriesPaginationPolicy are now tracked as backend-owned feature obligations. Evidence includes service duration, add-day, product coupon, price-table, voucher surcharge, pre-reservation coupon overpay, settlement line kind, care-team, distance provider, coverage, regional benefit, and document-series paths: source-refs/sanmopia-admin/application/config/constants.php:98, source-refs/sanmopia-admin/application/models/Reservation_model.php:643, source-refs/sanmopia-admin/application/controllers/Reservation.php:902, source-refs/sanmopia-admin/application/models/Reservation_model.php:1300, source-refs/sanmopia-admin/application/views/reservation_status/reservation_price_table.php:24, source-refs/sanmopia_web/application/models/Payment_model.php:758, source-refs/sanmopia-admin/application/models/Payment_model.php:1288, source-refs/sanmopia-admin/application/views/reservation_status/reservation_detail.php:1114, source-refs/sanmopia-admin/application/models/Matching_model.php:796, source-refs/sanmopia-admin/application/models/Branch_model.php:291, source-refs/sanmopia_web/application/controllers/api/Service.php:346, and source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3977. These items are not source-code-copy tasks. Each must become a versioned policy/profile/catalog/decision slice before UI or document rendering can consume it.
2026-07-05 persistent-agent source-dig addition: ExtraServiceBabyTypeSurchargePolicy, ReportMetricDateBasisPolicy, LegacySalesFeeMetricSnapshot, PerformanceEligibilityMetricRule, and CaregiverManualEvaluationAdjustmentPolicy are now tracked as source-parity risks. Evidence: source-refs/sanmopia-admin/application/models/Service_model.php:323-356, source-refs/sanmopia-admin/application/controllers/Reservation.php:1683-1687, source-refs/sanmopia-admin/static/js/reservation_status/reservation_add.js:1897-1912, source-refs/sanmopia-admin/application/models/Statistics_model.php:1070-1116, source-refs/sanmopia-admin/application/models/Statistics_model.php:1155-1173, source-refs/sanmopia-admin/application/models/Statistics_model.php:794-843, and source-refs/sanmopia-admin/application/controllers/Manager.php:194-240. Backend obligations: voucher Saturday/holiday baby-type surcharge eligibility must freeze catalog revision and not depend on UI TWINS_FL; report date buckets must stop merging months/quarters across years; sales fee metrics must replace GET_PAYMENT_FEE_RATIO with versioned fee snapshots; performance metrics must store eligibility rule versions and branch visibility; caregiver manual score edits must carry actor, score type, min/max policy, and explicit source-compat handling for the legacy HQ max-check bug. Backend foundation now includes ExtraServiceBabyTypeSurchargePolicy, which selects standard versus multiple-birth extra-service unit price from a versioned catalog row and keeps source price-version refs as evidence, not branching authority.

Actor/context handoff:
```
flowchart LR
 Mother[Mother/FamilySponsor] --> Charge[pricing_settlement ExtraServiceBabyTypeSurchargePolicy]
 Branch[BranchOwner] --> Reports[business_reporting ReportMetricDateBasisPolicy LegacySalesFeeMetricSnapshot]
 HQ[HeadOfficeManager] --> Reports
 HQ --> Performance[caregiver_performance_recognition PerformanceEligibilityMetricRule CaregiverManualEvaluationAdjustmentPolicy]
 Branch --> Performance
 Care[CareManager] --> Performance
 Charge --> Docs[document_reporting frozen charge/report artifacts]
 Reports --> Docs
 Performance --> Docs
```
Migration gates:
- Mother/FamilySponsor charge projections expose baby-type surcharge eligibility from frozen catalog/service-day evidence, not browser flags.
- BranchOwner and HeadOfficeManager report dashboards share one metric catalog where date basis, sales fee snapshot, branch scope, and export revision are immutable.
- CareManager recognition views read published scorecards only; HeadOfficeManager and permitted BranchOwner edits create manual adjustment ledger entries with cap-policy evidence and downstream grade invalidation.
2026-07-05 source-dig addition for reporting and voucher remap edge cases: BusinessPerformanceFunnelSnapshot, SalesRecognitionBasisReport, ScopedReportBranchVisibilityPolicy, CaregiverEvaluationCronScoreLedger, VoucherServiceBalanceOverrideFloor, ServiceBalanceAdditionalServiceChargeDecision, AdditionalServiceCatalogVersionRemap, PreReservationCouponOverCredit, ConvertedReservationOverCredit, AdminCancellationVoucherRefundStatusEdge, PaymentChangeZeroPayableCompletion, and VoucherPureAdditionalServiceBalance are exact source-parity gaps. Evidence: source-refs/sanmopia-admin/application/controllers/Statistics.php:283-323, source-refs/sanmopia-admin/application/models/Statistics_model.php:24-62, source-refs/sanmopia-admin/application/controllers/Statistics.php:436-460, source-refs/sanmopia-admin/application/models/Statistics_model.php:1885-1930, source-refs/sanmopia-admin/application/controllers/Statistics.php:27-43, source-refs/sanmopia-admin/application/controllers/cli/Manager.php:22-100, source-refs/sanmopia-admin/application/libraries/ManagerEvaluationLib.php:76-266, source-refs/sanmopia-admin/application/controllers/Reservation.php:486-505, source-refs/sanmopia-admin/application/controllers/Reservation.php:1819-1847, source-refs/sanmopia-admin/application/models/Reservation_model.php:5623-5759, source-refs/sanmopia-admin/application/models/Reservation_model.php:5985-6012, source-refs/sanmopia-admin/application/models/Service_model.php:238-260, source-refs/sanmopia_web/application/models/Payment_model.php:232-270, source-refs/sanmopia_web/application/models/Payment_model.php:775-841, source-refs/sanmopia_web/application/models/Payment_model.php:857-896, source-refs/sanmopia-admin/application/models/Reservation_model.php:1827-1856, and source-refs/sanmopia-admin/application/models/Payment_model.php:4155-4182. Backend obligations: funnel metric buckets, payment-date sales recognition, branch-visible report scope, score cron run ledger, voucher additional-service catalog remap, additional-service effective-day basis, pre-reservation over-credit, converted-reservation over-credit, admin refund status classification, zero-payable payment-change completion, and VoucherPureAdditionalServiceBalance must become named policy/snapshot facts. UI filters, source branch ids, source status ids, and mutable payment row rewrites cannot be authority. Formula-level gaps: persist posted_service_balance_krw, frozen voucher additional-service amount, pure_additional_service_balance_krw, price-version evidence, reason code, and repair-required flag; route negative pure-additional edge cases through operator repair instead of silent row rewrites. Backend foundation now includes ServiceBalanceAdditionalServiceChargePolicy, which reuses AdditionalServiceChargePolicy to freeze caregiver before-tax pay, base-service days, Saturday/holiday extension count, effective service days, additional-service charge amount, and final service-balance amount in one decision. 2026-07-07 naming hardening replaced backend/contract add_option_amount_krw and public addOptionAmountKrw with additional_service_amount_krw and additionalServiceAmountKrw in voucher catalog snapshots, keeping source add-option labels only in evidence rows. Backend foundation also includes PreReservationCouponOverCreditPolicy, which injects the required down-payment amount through a versioned rule, returns provider-payment versus zero-provider-payment closeout, and plans point plus shopping-mall-coupon over-credit grants from source-refs/sanmopia_web/application/models/Reservation_model.php:1401-1414, source-refs/sanmopia_web/application/models/Payment_model.php:775-841, and source-refs/sanmopia_web/application/controllers/api/Payment.php:537-544. Backend foundation now also includes ConvertedReservationOverCreditPolicy, which preserves the source-refs/sanmopia_web/application/models/Payment_model.php:232-270 three-branch point formula for converted-reservation closeout, including the extra coupon-prepayment grant when own price is below pre-reservation price. Persistence, entitlement outbox, and closeout workflow binding remain open.

Actor/context handoff:
```
flowchart LR
 Branch[BranchOwner] --> Balance[pricing_settlement VoucherPureAdditionalServiceBalance]
 HQ[HeadOfficeManager] --> Balance
 Balance --> Closeout[ServiceBalancePaymentCloseout]
 Balance --> Payout[CaregiverPayoutStatement]
 Balance --> Settlement[SettlementStatementWorkflow]
 Balance --> Docs[document_reporting charge and receipt artifacts]
```
Migration gates:
- Branch/HQ service-balance projections expose posted balance, voucher add-on, pure-additional balance, reason code, and repair state from backend policy facts only.
- Service-balance closeout, caregiver payout, settlement, and receipt artifacts consume the same VoucherPureAdditionalServiceBalance snapshot.
- Price-table and operator repair screens submit commands with actor, reason, expected revision, and idempotency key; no portal recomputes voucher add-on subtraction.

2026-07-03 Additional Hotspot Queue

Focused page: Promotion Caregiver Analytics Gap Mining. Additional focused page: Customer Account And Reservation Intake Gap Mining. Self-service focused page: Customer Self-Service Workspace Gap Mining. Partner benefit focused page: Partner Benefit Fulfillment Gap Mining. Traffic-spike focused page: Traffic Spike Backpressure Gap Mining. Notification/document-delivery focused page: Notification And Document Delivery Gap Mining.

Mother And Public Web

Admin And Branch Backoffice

Caregiver Manager App

Native Shell And Platform

Mother Android webview shell: splash, Kakao SDK, native bridge, payment scheme, push message service. Status: Pending. Evidence: sanmopia_android/app/src/main/java/com/sanmopia/app/*.
Mother iOS webview shell and Kakao framework integration. Status: Pending. Evidence: sanmopia_ios/ios_sanmopia_app/*, sanmopia_ios/KakaoOpenSDK.framework/*.
Manager Android shell. Status: Pending. Evidence: sanmopia_manager_android/app/src/main/*.
Source Docker/database/price-table import parity. Status: Partial. Evidence: sanmopia-docker/*, sanmopia-price-table/*, sanmopia-admin/application/controllers/cli/Price.php. Modern replacement: Stage/runtime infra is managed through repo SSOT and Traefik/Mutagen development flows. The stage now includes self-hosted Supabase core services (db, auth, rest, realtime, storage, imgproxy, kong) instead of only pointing env vars at missing db/kong hosts. Price workbook import uses the Supabase-first price_catalog_import slice rather than PHP CLI table mutation. Supabase Postgres initialization now follows the self-hosted image contract by preserving the image default POSTGRES_USER=supabase_admin; stage recovery docs explain how to reset only broken local Supabase volumes. Stage migrations now use a private migration ledger, and JWT key signatures are checked before Kong/PostgREST runtime use.

Modern Replacement Tracking

2026-07-06 Planck Backend Rule Mining

These entries are source-mined backend policy gaps found in the reservation -> payment/refund -> caregiver matching/payroll -> branch/HQ settlement -> documents path. They focus on legacy UI/PHP calculations, status strings, raw ids, and branch exceptions that must move into backend domain rules or adapter evidence instead of modern frontend logic.

2026-07-06 Frontend Lane Hidden PHP/UI Delta

This pass is docs-only. Source PHP/views remain evidence. These feature IDs mark UI-side state, authorization, and one-shot participation logic that must move to backend commands or read models before frontend implementation.

Feature ID	Hidden source behavior	Source path evidence	Modernization target	Implementation status	Backend-owned replacement
`SFC-20260706-UI-001`	Reservation wizard state is carried through query strings, including contact data, delivery facts, resident-number fragments, pet/religion preferences, ranking answers, service type, extra service days, rental choices, and question answers. The old survey final/complete pages also compute visible service price, government support, customer share, additional-service totals, and service-balance text from embedded `basePrice` and option variables in browser script.	`source-refs/sanmopia_web/application/models/Survey_model.php:8-71`, `source-refs/sanmopia_web/application/controllers/Survey.php:17-179`, `source-refs/sanmopia_web/application/views/survey/a27.php:284-331`, `source-refs/sanmopia_web/application/views/survey/a30.php:241-288`	`reservation_operations / ReservationIntakeDraftSession`, `member_management / SensitiveReservationPartyDraft`, `pricing_settlement / IntakeQuoteContext`, `IntakeQuotePreviewSnapshot`	`Backend foundation: 5da76dd`	Replace `dataLink*` URL state with backend draft tokens, encrypted sensitive draft fields, per-step validation, source evidence keys, expiration, explicit discard/submit commands, and catalog/version references. Frontend must not preserve PII or quote-affecting facts in URLs, and survey/booking UIs must render a backend `IntakeQuotePreviewSnapshot` instead of calculating support, customer-share, additional-service, or service-balance amounts from embedded price maps.
`SFC-20260706-UI-002`	Caregiver portal reservation buckets are filtered from Korean status labels plus current date, and access checks are ad hoc main/sub caregiver SQL predicates. Pay rows expose reservation/payment data from the same read path.	`source-refs/sanmopia-manager/application/models/Reservation_model.php:13-47`, `source-refs/sanmopia-manager/application/models/Reservation_model.php:89-91`, `source-refs/sanmopia-manager/application/controllers/User.php:931-953`, `source-refs/sanmopia-manager/application/models/Reservation_model.php:414-422`, `source-refs/sanmopia-manager/application/controllers/Other.php:223-237`, `source-refs/sanmopia-manager/application/helpers/salary_helper.php:8-40`	`care_delivery / CaregiverWorkReservationProjection`, `operator_access / CareManagerReservationAccessDecision`, `pricing_settlement / CaregiverPayoutReadinessProjection`	`Backend foundation: 1bd7e42`	Backend now has `care_delivery/features/caregiver_work_reservation_projection` with caregiver-scoped `active_work`, `completed_work`, and `payout_ready` buckets, assignment role, handoff order, service window, backend-masked mother/contact fields, payout readiness, disabled reasons, projection revision, and Pydantic boundary contracts. Runtime follow-up: Supabase projection adapter, route binding for caregiver portal lists/detail/pay screens, SpiceDB/RLS access checks, payout statement summary binding, 90-day privacy window policy, and legacy bucket adapter/disable path.
`SFC-20260706-UI-003`	Caregiver-to-HQ request edit/delete flows accept request ids from forms and model writes by request id only after the view loads with `managerId`; edit/delete lacks a durable expected revision or actor-scoped command.	`source-refs/sanmopia-manager/application/controllers/Other.php:335-384`, `source-refs/sanmopia-manager/application/controllers/Other.php:574-596`, `source-refs/sanmopia-manager/application/models/Request_model.php:24-49`	`caregiver_engagement / CaregiverOfficeRequestThread`, `operator_access / CaregiverRequestAuthorizer`, `communication_delivery / HeadquartersRequestReplyNotification`	`Backend foundation: 7f56280`	Backend now upgrades `caregiver_engagement/features/caregiver_office_request` with revisioned edit/delete mutation policy, caregiver/HQ/branch actor vocabulary, actor ownership and branch-scope checks, expected thread version, reply-state guard, soft-delete retention outcome, notification instruction, append-only audit event, and Pydantic mutation boundary contracts. Runtime follow-up: Supabase revision persistence, RLS/SpiceDB authorizer, request-thread mutation API, notification workflow binding, and legacy form adapter/disable path.
`SFC-20260706-UI-004`	Caregiver surprise-event participation is a one-shot insert keyed only by manager id; source checks whether any row already exists, hardcodes event type `1`, and stores freeform title/content.	`source-refs/sanmopia-manager/application/controllers/Other.php:402-413`, `source-refs/sanmopia-manager/application/controllers/User.php:957-981`, `source-refs/sanmopia-manager/application/models/User_model.php:2209-2234`	`caregiver_engagement / CaregiverCampaignParticipation`, `customer_engagement / CampaignSubmissionPolicy`, `operator_access / CaregiverCampaignEligibilityProjection`	`Backend foundation: b54084e`	Backend now has `caregiver_engagement/features/caregiver_campaign_participation` with campaign code/type/version instead of numeric type `1`, eligibility window, one-submission rule, content validation, consent terms, prior participation fact, idempotency key, admin review instruction, audit event, and Pydantic boundary contracts. Runtime follow-up: Supabase participation/audit persistence, campaign policy snapshot adapter, SpiceDB/RLS eligibility check, admin review queue binding, and legacy surprise-event adapter/disable path.
`SFC-20260706-UI-005`	Caregiver self-service address and device-token updates are direct profile mutations; address update geocodes raw address inline, and FCM token update replaces delivery endpoint state without device/audit vocabulary.	`source-refs/sanmopia-manager/application/controllers/User.php:716-813`, `source-refs/sanmopia-manager/application/controllers/User.php:787-797`, `source-refs/sanmopia-manager/application/models/User_model.php:866-917`	`caregiver_management / CaregiverProfileRevision`, `caregiver_assignment / CaregiverTravelEvidenceInvalidation`, `communication_delivery / CaregiverDeviceEndpointRegistration`	`Backend foundation: bf38296`	Backend now has `caregiver_management/features/caregiver_profile_contact_revision` with expected profile revision guard, provider-neutral address-normalization evidence, coordinate freshness, profile revision instruction, assignment/travel evidence invalidation, push device endpoint registration/replacement with token hash references, retryable provider failure decisions, audit events, and Pydantic boundary contracts. Runtime follow-up: Supabase profile/audit/endpoint persistence, address-normalization adapter, matching/travel cache invalidation job, RLS/SpiceDB caregiver ownership checks, notification provider endpoint binding, and legacy `type=fcm`/`type=address` adapter/disable path.

2026-07-08 Frontend Reservation UX Evidence

feature_id	lane_owner	source_evidence	ddd_aggregate	command_query	persistence	contract	e2e_proof	status
`SFC-20260708-UX-001`	Frontend lane	`frontend-repo/src/ui/organisms/FamilyAssistedReservationFlow.tsx`, `frontend-repo/src/ui/templates/MotherBookingTemplate.astro`, and `frontend-repo/src/lib/mother-booking-operational-context-client.ts`	`reservation_operations / ReservationBookingOperationalContext`, `pricing_settlement / BookingPaymentMethodSelection`, and `frontend_experience / MotherBookingCardFlowEvidence`	`GetMotherBookingOperationalContextQuery`, `StartReservationBookingWorkflowCommand`, `GetReservationBookingWorkflowRequestQuery`, and `CreatePaymentProviderRoutePreRegistrationCommand`	No frontend persistence; Nanostores hold card-state only while backend owns context, payment method options, quote, status, and progress projections. Frontend `8a9a6f5` removes production smoke settlement state and local ledger preparation.	`/mother-booking-operational-context`, `/reservation-booking-workflow-starts`, `/reservation-booking-workflow-requests/{bookingRequestId}`, and payment pre-registration route when enabled. Manual receipt command remains locked until backend draft exposes `expectedPaymentRevision`.	`frontend-repo/output/playwright/reservation-ux-progress-neutral-20260711/desktop-summary.json`, `mobile-summary.json`, desktop/mobile screenshots, 96 changed tests, ESLint, and Astro check prove no free-text composer, no mobile step clipping, neutral/semantic palette, no failed requests, and no production smoke endpoint. 2026-07-13 follow-up `frontend-repo/output/playwright/reservation-chat-sequential-20260713/` proves desktop/mobile one-question-at-a-time advancement across all 11 cards, answer transcript, completed-only summary reveal, current-card focus/scroll, no failed HTTP responses, and preserved backend-owned final values. Current run did not submit because stage mother session was absent.	`foundation`: frontend remains presentation-only and fail-closed, while prior 2026-07-09 stage proof established browser booking. Refresh Supabase mother/operator sessions and rerun current commit through booking, payment, dev-smoke/backend settlement driver, and real settlement projection before `e2e_proven`.

| SFC-20260711-UX-002 | Frontend lane | Legacy-like frontend debt in committed modern code inferred settlement repair actions from workflow status, warning tone from reconciliation amount, and rendered smoke-only settlement facts in production source. | frontend_experience / BackendOwnedActionDescriptor, pricing_settlement / SettlementRepairActionProjection | GetSettlementRepairActionsQuery, existing backend retry/cancel commands | No frontend persistence. Frontend 8a9a6f5 removes production smoke DTO/state/rendering and moves examples to colocated tests. | Backend projection must return allowed retry/cancel descriptors, disabled reason, expected revision, and command path/reference; frontend may not derive them from publicStatus or retryState. | Focused tests prove retry/cancel stay absent without descriptor; ESLint blocks reservation-smoke-scenarios and SmokeSettlement under src/**; Playwright desktop/mobile has zero console/network errors. | foundation | Keep controls disabled until backend repair-action descriptor exists. Playwright harness alone may invoke dev-smoke endpoint and then inspect real settlement projection. |

2026-07-06 Feature Checklist Curator Addendum

These rows are narrow additions only. They avoid replacing existing broad payment, settlement, RBAC, document, service-calendar, and family-authority items, and preserve source path/function/menu hints for later implementation. This table is legacy human-readable format. Rows added or touched after 2026-07-07 should also expose the canonical machine-countable fields above or carry equivalent field values in notes until the table is mechanically split.

Feature ID	Missing source behavior	Source path evidence	Modernization target	Implementation status	Backend-owned replacement
`SFC-20260706-CUR-001`	Sales/statistics screens support revenue views, but Kanboard requires self-service National Tax Service/tax-audit/payment-method evidence exports. Current checklist covers analytics and privacy retention, not an export artifact with legal/tax evidence purpose, immutable dataset revision, masked fields, and actor audit.	`source-refs/sanmopia-admin/application/controllers/Statistics.php:433-507` (`getStatisticForSales`, `getDataTableForSales`), `source-refs/sanmopia-admin/application/models/Statistics_model.php:1063-1098` (`getSalesStatisticsForMain`), `source-refs/sanmopia-admin/application/models/Statistics_model.php:1786-1818` (`getDataTableForSalesDetail`), `source-refs/sanmopia-admin/static/js/statistics/sales.js:636-652`, `source-refs/sanmopia-admin/static/js/statistics/sales.js:740-760`, `assembly-repo/apps/docs/src/content/docs/migration-source-map/kanboard-renewal-feature-improvements.md:278-309`	`business_reporting / TaxEvidenceExportArtifact`, `pricing_settlement / SettlementEvidenceDatasetRevision`, `operator_access / EvidenceExportPermission`	`Backend foundation: e3e9ad6`; `Cash receipt dataset bridge: d79aeb6`	Add export request command with purpose code (`national_tax_submission`, `tax_audit`, `payment_method_breakdown`), source metric catalog version, settlement/payment ledger revision, branch/HQ scope, field masking profile, generated artifact grant, reviewer-visible checksum, and append-only audit. UI must not use DataTables state or chart totals as evidentiary export authority. `d79aeb6` adds the cash-receipt settlement tax-evidence dataset revision bridge with checksum-verified rows, masked identity references, cash-receipt approval/reversal kind, ledger revision, source evidence keys, and Pydantic boundary payloads.
`SFC-20260706-CUR-002`	Lovebox/Momfirst DB export is split between scheduled CSV mail, hardcoded recipient constants, admin filters, and send/no-send flags. Kanboard asks for monthly extraction, daily recipient management, recipient-change history, and privacy-scoped permissions. Existing `MomfirstDelivery` item does not name recipient schedule/change history.	`source-refs/sanmopia_web/application/controllers/cli/Clean.php:1-25` (`scheduler_send_csv_data` cron hint), `source-refs/sanmopia_web/application/controllers/cli/Clean.php:58-125` (`makeSendCsvData` temp CSV/mail flow), `source-refs/sanmopia_web/application/models/Momfirst_model.php:457-468` (`putLogForNotSendList`), `source-refs/sanmopia_web/application/models/Momfirst_model.php:490-542` (CSV row build), `source-refs/sanmopia-admin/application/views/promotion/momfirst.php:64-75` (Lovebox/Milk filter + download), `source-refs/sanmopia-admin/application/controllers/Promotion.php:470-482`, `assembly-repo/apps/docs/src/content/docs/migration-source-map/kanboard-renewal-feature-improvements.md:471-491`	`customer_engagement / PartnerBenefitRecurringExportSchedule`, `document_reporting / PartnerBenefitDatasetArtifact`, `operator_access / PartnerExportRecipientGrant`	`Backend foundation: c4d0a40`	Replace hardcoded email constants and temp CSV deletion with versioned recipient schedules, monthly/daily export plans, dataset snapshot ids, send/no-send reason events, privacy export permission, delivery attempt ledger, artifact retention, recipient change audit, and signed download/mail grants.
`SFC-20260706-CUR-003`	Printable documents copy reservation free-text/`기타 요청사항` into fixed spreadsheet cells. Kanboard calls out line breaks, long text, and font-size handling for initial consultation/reservation intake documents; current template registry item does not name free-text layout policy.	`source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3558-3607` (`PREFERENCE_ETC->CONTENT` into cell `B17`), `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4098-4104` (`DOCUMENT_DATA_ID_FIRST_CONSULT_REPORT`), `assembly-repo/apps/docs/src/content/docs/migration-source-map/kanboard-renewal-feature-improvements.md:250-266`	`document_reporting / PrintableFreeTextLayoutPolicy`, `ReservationIntakeDocumentProjection`, `DocumentRenderAttempt`	`Backend foundation: a31229f`	Add backend-owned free-text layout decision with source field key, max display length, wrapping/newline policy, font-size downgrade rules, overflow artifact warning, template version, and render-attempt evidence. Operators edit structured note fields; renderers receive layout decisions instead of raw text dropped into fixed cells.
`SFC-20260706-CUR-004`	Repeated Kanboard requests ask for admin-run pre-reservation transfer with target/result/failure/actor fields. Source evidence found only pre-reservation detail routing, customer conversion eligibility, and payment/check pages, not a durable operator transfer command. This is distinct from customer pre-reservation conversion.	`assembly-repo/apps/docs/src/content/docs/migration-source-map/kanboard-renewal-feature-improvements.md:471-491`, `source-refs/sanmopia-admin/application/controllers/Reservation.php:444-455` (`pre_reservation_detail` routing), `source-refs/sanmopia_web/application/controllers/api/Reservation.php:450-472` (`isPreReservation`), `source-refs/sanmopia_web/application/controllers/Service.php:703-776` (`preReservationPayment`)	`reservation_operations / PreReservationManualTransferRun`, `migration_governance / OperatorDataTransferAudit`, `operator_access / PreReservationTransferPermission`	`Backend foundation: 5442c31`	Add an operator command for pre-reservation transfer/backfill with source reservation id, target booking/customer/branch scope, dry-run diff, eligibility reason, failed-row reason, actor/reason, idempotency key, expected source revision, payment/coupon/document impact plan, and immutable transfer audit. Do not reuse customer conversion UI as admin migration authority.
`SFC-20260706-CUR-005`	Customer point import is a CLI spreadsheet runner that reads uploaded workbook rows, carries the previous non-empty point value forward, matches user by name/phone, and writes points inside one transaction with optional rollback. It has no workbook hash, idempotency, actor reason, row-level failure artifact, or point-ledger import run identity.	`source-refs/sanmopia-admin/application/controllers/cli/Point.php:10-84`, `source-refs/sanmopia_web/application/models/User_point_model.php:10-25`	`customer_engagement / CustomerPointBulkImportRun`, `pricing_settlement / CustomerPointLedgerEntry`, `operator_access / BulkPointImportPermission`	`Backend foundation: 1b36666`	Backend now has `customer_engagement/features/customer_point_bulk_import` with dry-run/apply plans, workbook artifact hash, source row number, normalized phone, match decision, carried-forward amount evidence, actor/reason, idempotency key, ledger-line instruction, failure reasons, and import summary. Runtime follow-up: workbook parser/import adapter, Supabase point ledger persistence, permission check, failure artifact storage, and operator UI binding.
`SFC-20260706-CUR-006`	Customer activity telemetry accumulates page dwell time and visit counts through web controllers and log models, caps detail time in PHP, and later reads aggregates for statistics. Route strings, time caps, consent, retention, and analytics projection ownership are implicit.	`source-refs/sanmopia_web/application/views/nav/bottom_nav.php:83-110`, `source-refs/sanmopia_web/application/controllers/Common.php:10-68`, `source-refs/sanmopia_web/application/models/User_log_model.php:11-108`, `source-refs/sanmopia-admin/application/models/Statistics_model.php:2204-2224`	`business_reporting / CustomerActivityTelemetrySession`, `customer_engagement / CustomerActivityConsentScope`, `platform_observability / CustomerActivityAggregateProjection`	`Backend foundation: 409f146`	Backend now has `business_reporting/features/customer_activity_telemetry` with server-issued telemetry session id, stable route catalog key/version, source URL hash reference instead of raw URL, consent and retention facts, capped event/session dwell seconds, dedupe token, connect type code, aggregate projection revision/delta, append-only audit event, and Pydantic boundary contracts. Runtime follow-up: Supabase session/detail/aggregate persistence, route catalog adapter, consent policy binding, reporting projection API, and legacy `countVisit` adapter/disable path.
`SFC-20260706-CUR-007`	Shopping-mall coupon batch issue is a disabled controller method with hardcoded creator, reason, user list, price, coupon type, and HTML echo output. Re-enabling it would mint coupons and user coupon links without dry-run, uploaded recipient artifact, idempotency, or entitlement ledger.	`source-refs/sanmopia_web/application/controllers/management/Coupon.php:5-68`	`pricing_settlement / ManualShoppingMallCouponBatchIssueRun`, `customer_engagement / ShoppingMallCouponEntitlement`, `operator_access / CouponBatchIssuePermission`	`Backend foundation: a85a5bb`	Backend now has `pricing_settlement/features/promotion_entitlement/manual_shopping_mall_coupon_batch_issue` with disabled-by-default gate, uploaded recipient artifact hash/reference, dry-run/apply mode, row validation, coupon catalog/version through `PromotionEntitlementRule`, actor/reason, idempotency key, entitlement instruction, failed-row reason, and operator audit basis. Runtime follow-up: Supabase entitlement persistence, recipient parser, permission check, failure artifact storage, and operator UI binding.
`SFC-20260710-CUR-105`	Member-screen operators can issue a one-off gift coupon from a modal by entering free-form coupon name and discount amount. The browser posts those values to `/member`; the controller passes them through; the model immediately creates a gift coupon plus user-coupon grant with current publication time; coupon history then treats gift coupons as issued and exposes their mutable use/delete/refund state. This is distinct from disabled shopping-mall batch issue, product gift-coupon entitlement, and gift-coupon checkout.	`source-refs/sanmopia-admin/application/views/member/member_inquiry.php:99-115`, `source-refs/sanmopia-admin/application/views/modal/modal_coupon_publish.php:14-25`, `source-refs/sanmopia-admin/static/js/member/member_inquiry.js:25-34`, `source-refs/sanmopia-admin/static/js/modal/modal_coupon_publish.js:33-50`, `source-refs/sanmopia-admin/application/controllers/Member.php:39-71`, `source-refs/sanmopia-admin/application/models/User_model.php:420-458`, `source-refs/sanmopia-admin/application/models/Coupon_model.php:503-521`, `source-refs/sanmopia-admin/application/models/Coupon_model.php:568-583`, `source-refs/sanmopia-admin/application/models/Coupon_model.php:642-693`	`promotion_entitlement / OperatorIssuedGiftCouponGrant`, `pricing_settlement / ReservationDiscountCouponImpact`, `operator_access / CouponIssuancePermission`	`Partial`	Add a backend command for one-off operator coupon grants with actor scope, recipient member snapshot, coupon catalog/rule version, amount bounds, approval/reason, idempotency key, entitlement ledger row, user-grant publication fact, and downstream payment/refund/settlement impact plan. Admin UI may request a grant and display projected state only; it must not make coupon name, amount, publication, or deletion/refund readiness authoritative from modal fields or mutable coupon rows.
`SFC-20260706-CUR-008`	Caregiver app persistent login stores encrypted `AUTH_TOKEN` in a 10-year `stay` cookie and restores CI session directly from that cookie. Password login rotates `MANAGER_TB.AUTH_TOKEN`, but stay-login has no backend refresh-token record, device binding, rotation-on-use, revocation ledger, or audit trail.	`source-refs/sanmopia-manager/application/models/Auth_model.php:7-44`, `source-refs/sanmopia-manager/application/libraries/Loginlib.php:36-50`, `source-refs/sanmopia-manager/application/libraries/Loginlib.php:59-83`, `source-refs/sanmopia-manager/application/models/User_model.php:24-38`	`caregiver_management / CaregiverPersistentSessionGrant`, `operator_access / CaregiverSessionRecoveryPolicy`, `security_audit / PersistentLoginAuditEvent`	`Backend foundation: 8d6b368`	Backend now has `caregiver_management/features/caregiver_persistent_session_grant` with server-side token hash references, device binding, caregiver eligibility fact, issue/use/revoke commands, rotation-on-use, logout-all scope, denied-use reasons, append-only audit event, and Pydantic boundary contracts. Runtime follow-up: Supabase grant persistence, hashed refresh-token storage, Supabase Auth actor binding, SpiceDB/OPA operator revocation checks, RLS policies, and caregiver-app session API binding.
`SFC-20260706-CUR-009`	Caregiver app sends a free-text “tell headquarters” SMS from raw request `cellphone` and `message` values. It has no authenticated caregiver actor, recipient policy, moderation/retention boundary, idempotency, provider-neutral dispatch record, delivery result, or append-only contact audit.	`source-refs/sanmopia_web/application/controllers/api/Manager.php:52` (`managerWriteFaq`), `source-refs/sanmopia_web/application/libraries/Aligolib.php:27`	`caregiver_engagement / CaregiverHeadquartersContactCommand`, `communication_delivery / SmsDispatchRequest`, `operator_access / CaregiverHeadquartersContactPermission`	`Backend foundation: 02fb3ed + 07f6824`	Backend now has `caregiver_engagement/features/caregiver_headquarters_contact` with authenticated caregiver actor, branch context, headquarters recipient policy, normalized retained message body, moderation fact, provider-neutral SMS dispatch instruction without raw phone or raw message-body payload, idempotency key, append-only audit event, and Pydantic boundary contracts. Runtime follow-up: Supabase contact/audit persistence, communication workflow binding, recipient policy storage, provider delivery result projection, SpiceDB/RLS permission checks, and legacy `managerWriteFaq` adapter/disable path.
`SFC-20260706-CUR-010`	Reservation free-text care instruction is captured as “other service/special note” and reused for matching and caregiver schedule, but legacy deletes/reinserts one mutable row with no revision, actor, retention, masking, or instruction visibility contract.	`source-refs/sanmopia_web/application/models/Smart_matching_model.php:272` (`insertReservationPreferenceEtc`), `source-refs/sanmopia-admin/application/models/Matching_model.php:207` (`loadReservationPreferenceEtcInfoByUserId`), `source-refs/sanmopia-manager/application/controllers/Schedule.php:29` (`schedule_info` loads caregiver-visible instruction), `source-refs/sanmopia-manager/application/views/service/service.php:550` (`기타 서비스(필요시, 직접 기재)`)	`care_delivery / ReservationCareInstructionSnapshot`, `caregiver_assignment / MatchingCarePreferenceEvidence`, `care_delivery/features/reservation_care_instruction`	`Backend foundation: 41b3913`	Backend now has `care_delivery/features/reservation_care_instruction` with revision-checked record command, normalized body, author actor/surface, instruction kind, sensitivity policy, matching visibility evidence, caregiver-schedule visibility window, hidden reason codes, append-only audit event, and Pydantic boundary contracts. Runtime follow-up: Supabase snapshot/audit persistence, matching read-model binding, caregiver schedule projection API, retention/masking policy storage, SpiceDB/RLS checks, and legacy preference-row import adapter.
`SFC-20260706-CUR-011`	Manager app has a hidden `forceLogin` support path: IP whitelist plus daily shared password plus GET `id` rotates the target caregiver `AUTH_TOKEN` and logs in as that caregiver, without operator actor, reason, approval, expiry, revocation, or audit.	`source-refs/sanmopia-manager/application/controllers/Test.php:12` (`forceLogin`), `source-refs/sanmopia-manager/application/controllers/Test.php:29` (IP whitelist), `source-refs/sanmopia-manager/application/controllers/Test.php:39` (`id`/`pwd` GET gate), `source-refs/sanmopia-manager/application/controllers/Test.php:57` (`setAuthToken`), `source-refs/sanmopia-manager/application/models/User_model.php:24` (`setAuthToken`)	`operator_access / CaregiverSupportImpersonationGrant`, `security_audit / SupportImpersonationAuditEvent`, `operator_access/features/support_impersonation`	`Backend foundation: adcc4cb`	Backend now has `operator_access/features/support_impersonation` with authenticated support actor, target caregiver fact, ticket/reason, approval fact, IP/device hash-reference constraints, short-lived grant window, target-token mutation block, explicit revoke command, idempotency key, append-only audit event, branch/headquarters/security actor vocabulary, and Pydantic boundary contracts. Runtime follow-up: Supabase grant/audit persistence, SpiceDB/RLS authorization checks, support-session API binding, revocation endpoint, and legacy force-login import/disable adapter.
`SFC-20260706-CUR-012`	Customer web API has hidden `forceLogin`: IP whitelist plus daily shared password plus GET `id` logs in as any customer using existing `USER_TB.AUTH_TOKEN`, without support actor, ticket/reason, approval, expiry, revocation, or audit. This is distinct from caregiver support impersonation.	`source-refs/sanmopia_web/application/controllers/api/Test.php:15` (`forceLogin`), `source-refs/sanmopia_web/application/controllers/api/Test.php:32` (IP whitelist), `source-refs/sanmopia_web/application/controllers/api/Test.php:41` (`id`/`pwd` GET gate), `source-refs/sanmopia_web/application/controllers/api/Test.php:47` (`USER_TB.AUTH_TOKEN` lookup), `source-refs/sanmopia_web/application/controllers/api/Test.php:52` (`authlib->setLogin`)	`operator_access / CustomerSupportImpersonationGrant`, `member_management / CustomerAccountSupportSession`, `security_audit / CustomerSupportImpersonationAuditEvent`	`Backend foundation: 2ef4ce1`	Backend now has `operator_access/features/support_impersonation/customer_support_impersonation` with authenticated support actor, customer account target, support-session scope, ticket/reason, approval fact, IP/device hash-reference constraints, short-lived grant window, target-token mutation block, explicit revoke command, customer-named audit event, idempotency key, and Pydantic boundary contracts. Runtime follow-up: Supabase grant/audit persistence, Supabase Auth support-session binding, SpiceDB/RLS authorization checks, revoke/end endpoint, and legacy customer `forceLogin` adapter/disable path.
`SFC-20260706-CUR-013`	Admin reservation detail/add flows infer payment paid/unpaid state and lifecycle movement from deposit-date fields and status text, while model code recalculates amount and rewrites payment rows.	`source-refs/sanmopia-admin/application/views/reservation_status/reservation_detail.php:1217-1272`, `source-refs/sanmopia-admin/static/js/reservation_status/reservation_add.js:1350-1379`, `source-refs/sanmopia-admin/application/controllers/Reservation.php:676-687`, `source-refs/sanmopia-admin/application/controllers/Reservation.php:849-859`, `source-refs/sanmopia-admin/application/controllers/Reservation.php:1538-1616`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:1566-1678`	`pricing_settlement / OperatorPaymentFactEditCommand`, `OperatorPaymentDateCorrectionPolicy`, `operator_access / OperatorPaymentFactEditPermission`	`Backend foundation: 8786359`; `Persistence: 5a2ac5c`; `API binding: ff4e996`; `Broad-save guard: 4f7b672`; `Amount snapshot backfill: 9de2d68`; `Projection refresh: 49245dc`; `Reservation-detail adapter facts: 183f8f4`; `Public contract: f230493`; `Frontend client: f9a14d2`	Backend now has `pricing_settlement/features/payment/operator_payment_fact_edit` with purpose-tagged manual payment fact edits, explicit paid/unpaid intent, recorded deposit date, expected payment revision, actor capability evidence, reason, idempotency key, immutable amount snapshot, correction audit, shared audit fingerprint helper, projection invalidation keys, Supabase handler/store port, idempotent correction lookup, RPC-backed correction persistence, payment-record revision/snapshot columns, restrict FK audit retention, protected HTTP/API contracts, backend-derived actor/capability evidence, main app handler wiring, receipt-path guard coverage that rejects legacy-style existing payment fact overwrite, historical payment-row amount snapshot backfill, new-row amount snapshot keys for receipt/pre-registration facts, payment-change board amount snapshot projection, settlement board/read-model invalidation for manual payment fact edits, reservation collaboration broad-save rejection for payment-date facts, and reservation-detail snapshot `payment_fact.operator_edit_targets` for command binding. Public contract now carries explicit edit intent, expected revision, frozen amount authority, date consistency, audit result, and projection invalidations; frontend client consumes that contract with authenticated transport. Runtime follow-up: bind reservation-detail command targets to the admin control organism and prove conflict/recovery behavior.
`SFC-20260706-CUR-014`	Gift-coupon checkout deletes older unpaid payment drafts for the same buyer before inserting a new payment row, so retry/idempotency, stale draft visibility, provider handoff lineage, and anonymous-buyer handling are hidden in destructive cleanup.	`source-refs/sanmopia_web/application/controllers/api/Shop.php:25-47`, `source-refs/sanmopia_web/application/models/Coupon_model.php:280-318` (`insertGiftCouponPaymentPrepare`), `source-refs/sanmopia_web/static/js/shop_gift.js:92-128`, `source-refs/sanmopia_web/application/views/shop/coupon_order.php:150-158`, `source-refs/sanmopia_web/application/controllers/api/Payment.php:235-296`, `source-refs/sanmopia_web/application/models/Payment_model.php:284-324`, `source-refs/sanmopia_web/application/models/Coupon_model.php:396-440`, `source-refs/sanmopia_web/application/libraries/Kcppayment.php:175-411`, `source-refs/sanmopia_web/application/libraries/Kcppayment.php:418-475`, `source-refs/sanmopia_web/application/controllers/api/Kcp.php:18-101`, `source-refs/sanmopia_web/application/models/Payment_model.php:512-734`	`pricing_settlement / GiftCouponCheckoutSession`, `pricing_settlement / GiftCouponPaymentDraftSupersessionFact`, `promotion_entitlement / GiftCouponOfferSelection`, `pricing_settlement / GiftCouponPaymentCloseout`, `promotion_entitlement / GiftCouponEntitlementIssuance`	`Backend foundation: f6f512a`; `Backend runtime API: 69e78cf`; `Backend closeout foundation: 6aef95c`; `Contract checkout: 811768e`; `Contract closeout: 2ba20fa`; `OpenAPI/schema: dbf3c96`	Backend now has `pricing_settlement/features/payment/gift_coupon_checkout` with `GiftCouponCheckoutSession`, buyer/receiver snapshots, offer/catalog selection, idempotency key, stale-unpaid cutoff, append-only `GiftCouponPaymentDraftSupersessionFact`, Pydantic application payloads, Supabase persistence for `sanmopia_gift_coupon_checkout_sessions` and `sanmopia_gift_coupon_payment_draft_supersession_facts`, backend-only RLS/grant guard, public TS/JSON contract, OpenAPI path, and `POST /gift-coupon-checkout-sessions` runtime binding. The HTTP boundary accepts camelCase contract payloads, rejects UI-only amount fields, and returns the backend-owned checkout plan; replacement is explicit supersession plus status update, not source-style delete-before-insert. Closeout now has `GiftCouponProviderPaymentFacts`, instant-payment vs virtual-account-deposit closeout kind, amount-matched `GiftCouponPaymentCloseoutPlan`, entitlement issuance instruction, buyer/receiver dispatch instructions, compensation-refund intent on entitlement-store failure, Pydantic payloads, and TS contract validation so UI cannot recompute paid amount, closeout outcome, or refund amount. Backend stage proof `pnpm supabase:smoke:stage:gift-coupon-closeout-side-effects` now ties a paid checkout/payment to issued promotional entitlement, fulfillment request, receiver fulfillment route, and frozen gift-coupon settlement template. Remaining migration: bind live Kill Bill payment attempt and virtual-account issue, ingest provider-originated deposit notifications, persist closeout plans in Supabase, expose closeout API/workflow handoff, execute recipient auto-registration by phone idempotently, connect refund compensation to Kill Bill, handle nonmember buyer later-claim, support resend without receiver mutation, gate used-coupon refund, materialize cancelled gift/product coupon commission lines, and backfill historical gift-coupon payment facts from `PAYMENT_COUPON_TB`.
`SFC-20260706-CUR-015`	Gift-coupon receiver change/resend verifies the original receiver name and phone as mutation authority; the source has an actual receiver update commented out, but still sends SMS to a new receiver phone.	`source-refs/sanmopia_web/application/controllers/api/Shop.php:105-109` (`couponResend`), `source-refs/sanmopia_web/application/controllers/api/Shop.php:132-169`, `source-refs/sanmopia_web/application/models/Payment_model.php:451-473` (`getCouponPaymentData`, `updateCouponPaymentInfo`)	`member_management / GiftCouponRecipientAuthoritySnapshot`, `promotion_entitlement / GiftCouponRecipientRevision`, `communication_delivery / GiftCouponResendDispatchRequest`	`Backend foundation: abba19b`; `Contract: 760838f`	Backend now has `GiftCouponRecipientAuthoritySnapshot`, `GiftCouponRecipientContactSnapshot`, `GiftCouponRecipientRevision`, `GiftCouponResendDispatchRequest`, and `GiftCouponRecipientRevisionPlan` under the promotion-entitlement slice. The policy requires buyer authority, expected current revision, unused/unregistered and unrefunded entitlement state, accepted receiver snapshot, source evidence keys, and one idempotent resend dispatch bound to the accepted revision. Pydantic and TS contracts validate the same plan so UI cannot send an arbitrary new receiver SMS that diverges from stored entitlement ownership. Runtime follow-up: Supabase recipient-revision persistence, direct-contact dispatch persistence, API/workflow binding, operator repair/audit history, and legacy receiver-change import adapter.
`SFC-20260706-CUR-016`	Gift-coupon refund order differs by channel: customer cancel marks refund/delete flags before provider refund success, while admin delete-coupon refunds first and then flags refunded/deleted.	`source-refs/sanmopia_web/application/controllers/api/Shop.php:178-204`, `source-refs/sanmopia_web/application/controllers/api/Shop.php:213-235`, `source-refs/sanmopia-admin/application/models/Coupon_model.php:163-186` (`deleteCoupon`), `source-refs/sanmopia-admin/application/models/Coupon_model.php:191-195`	`pricing_settlement / GiftCouponRefundSaga`, `pricing_settlement / PaymentRefundIntent`, `promotion_entitlement / GiftCouponEntitlementCancellation`	`Backend foundation: 8586f94`; `Contract: cadbb1b`	Backend now has `GiftCouponRefundableEntitlementSnapshot`, `GiftCouponRefundChannel`, `GiftCouponRefundSagaPlan`, and `GiftCouponEntitlementCancellationInstruction`. The policy reuses generic `PaymentRefundIntent`, requires buyer authority for customer self-service, rejects used/registered, already-refunded, or already-cancelled entitlements, and gates entitlement cancellation on `provider_refund_succeeded` so source refund/delete flags become projections after provider success. Pydantic and TS contracts validate refund amount, expected payment revision, entitlement id matching, and provider-first cancellation ordering. Runtime follow-up: Supabase saga persistence, Kill Bill refund execution, provider result ingestion, entitlement cancellation worker, operator repair/read API, and legacy refund flag backfill.
`SFC-20260706-CUR-017`	Gift-coupon expiration inserts a separate expiration row and then sets `USER_COUPON_TB.USE_FL=1`, conflating expired with consumed in later reads.	`source-refs/sanmopia_web/application/models/Coupon_model.php:38-40`, `source-refs/sanmopia_web/application/models/Coupon_model.php:216-248`, `source-refs/sanmopia_web/application/models/Coupon_model.php:628-653` (`expireCoupon`), `source-refs/sanmopia-admin/application/models/Coupon_model.php:656-664`	`promotion_entitlement / CouponExpirationLedger`, `promotion_entitlement / GiftCouponEntitlementState`, `pricing_settlement / ExpiredCouponSettlementVisibilityPolicy`	`Backend foundation: 42e4cd2`; `Contract: 3ab9a08`	Backend now has `CouponExpirationLedgerPolicy`, `CouponExpirationLedgerEntry`, `GiftCouponEntitlementState`, and `ExpiredCouponSettlementVisibilityPolicy`. It reuses the existing `PromotionEntitlement.expire` transition, records source expiration evidence separately, projects `expired` as not consumed, and preserves expired entitlement evidence for settlement/read models instead of reusing a consumed flag. Pydantic and TS contracts reject expired states that also claim consumed. Runtime follow-up: Supabase expiration ledger persistence, scheduled expiration worker, historical `USER_COUPON_EXP_TB` backfill, read-model migration away from `USE_FL`, and settlement visibility API binding.
`SFC-20260706-CUR-018`	Admin CLI can issue a raw KCP full refund from `ordr_idxx` and `tno` and only dumps provider response, bypassing reservation/payment-change refund intents, payment ledger state, settlement invalidation, actor reason, and repair audit. This is not covered by the partial-refund provider gate from backend `90e4b00` / contract `75aaebe`, which plans provider capability for domain refunds but does not replace raw repair/refund execution.	`source-refs/sanmopia-admin/application/controllers/cli/Kcp.php:12-24` (`refund`), `source-refs/sanmopia-admin/application/libraries/Kcppayment.php:31-60` (`refund`, `mod_type=STSC`)	`pricing_settlement / PaymentRefundRepairCommand`, `pricing_settlement / PaymentRefundLedgerReconciliation`, `operator_access / ProviderRefundRepairPermission`	`Backend foundation: b71f600`; `Persistence: 5241e3c`; `Permission binding: 69eb6d3`; `Internal planning route: current`; `Execution-attempt route: current`	Backend now has `PaymentRefundRepairCase`, `ProviderRefundRepairPermission`, `ProviderRefundRepairPaymentLookup`, `PaymentRefundRepairPolicy`, application handler/store port, and Pydantic boundary payloads, plus Supabase service-role persistence for repair cases, permission decisions, and repair plans in `5241e3c`, and a SpiceDB-backed `close_reservation_finance` permission checker that mints `ProviderRefundRepairPermission` in `69eb6d3`. The token-gated internal route `POST /internal/payment-refund-repairs/provider-refund-plans` now binds `PaymentRefundRepairHandler` to Supabase persistence. Repair planning must start from `PaymentLedger` + `PaymentRefundIntent` + approved repair case + non-expired provider-refund-repair permission + backend-owned provider lookup; it validates expected payment ledger revision, refund-intent revision, payment id, provider lookup match, idempotency, settlement invalidation key, and creates a normal `PaymentRefundGatewayCommand` through the append-only payment ledger instead of raw `ordr_idxx`/`tno` refund. The token-gated internal `POST /internal/payment-refund-repairs/provider-refund-executions` route now calls `PaymentGatewayClient.refund` only when no matching execution attempt already exists, persists idempotency-keyed execution attempts in `sanmopia_payment_refund_repair_execution_attempts`, replays matching stored attempts into the ledger-backed provider-result recorder, and rejects mismatched idempotency replays. Runtime follow-up: retry backoff/operator result-history projection, settlement read-model invalidation proof, customer/branch visibility policy, and legacy CLI disable/adapter path.
`SFC-20260706-CUR-019`	KCP payment flows carry cash-receipt request/result fields and virtual-account deposit callbacks carry cash-receipt approval fields, but provider closeout, customer receipt, and settlement evidence are persisted as generic provider JSON without a normalized cash-receipt snapshot. Source `getResultJson()` drops the `cash_*` values it already read, so tax/settlement evidence can diverge from provider approval.	`source-refs/sanmopia_web/application/helpers/util_helper.php:70-110` (`getPayResult`), `source-refs/sanmopia_web/application/libraries/Kcppayment.php:65-69`, `source-refs/sanmopia_web/application/libraries/Kcppayment.php:145-149`, `source-refs/sanmopia_web/application/libraries/Kcppayment.php:309-312`, `source-refs/sanmopia_web/application/libraries/Kcppayment.php:376-410` (`cash_*`, `getResultJson`), `source-refs/sanmopia_web/application/controllers/api/Kcp.php:60-88` (`putKcpNotification`)	`pricing_settlement / PaymentProviderCashReceiptEvidence`, `document_reporting / CustomerReceiptTaxEvidenceArtifact`, `business_reporting / SettlementTaxEvidenceDatasetRevision`	`Backend foundation: 098cccb`; `Provider closeout binding: bbe488e`; `Virtual-account notification adapter: 0f9c419`; `Customer receipt artifact projection: d247aba`; `Settlement tax dataset projection: d79aeb6`; `Visibility policy: e5a1571`; `Printable access handoff: 04690fa`; `Receipt render data: 24c5f40`; `Stored artifact binding: 2c0ce95`; `Legacy KCP backfill command: 203e179`; `Internal import endpoint: c48bbfc`	Backend now has provider-neutral `PaymentProviderCashReceiptEvidence`, issue-request and approval-evidence snapshots, payment commercial context, payment ledger revision, refund/reversal linkage, export visibility policy, Pydantic boundary payloads, application handler/store port, and Supabase service-role persistence for `sanmopia_payment_provider_cash_receipt_evidence`. Provider closeout and virtual-account deposit can now persist cash-receipt request flag, registration purpose, masked identity reference, approval number, transaction number/date, provider notification id, and tax/export visibility as append-only evidence instead of raw KCP JSON or provider receipt URL construction. Payment event ingestion now optionally saves cash-receipt evidence from verified provider payloads in `bbe488e`, skips raw `cash_id_info`, and does not block payment workflow when only unsafe identity data exists. `0f9c419` adds the matched KCP virtual-account cash-receipt notification adapter for `TX00` deposit callbacks, ignores cancel `op_cd=13`, requires a masked registration identity reference, and maps KCP approval/transaction numbers into append-only evidence. `d247aba` adds `CustomerReceiptTaxEvidenceArtifactSnapshot`, Pydantic boundary payloads, and the pricing-settlement projection from provider cash-receipt evidence to a customer-safe tax-evidence artifact; provider order ids, provider payment refs, and transaction refs remain backend-only evidence and settlement-only cash receipts are rejected from the customer artifact projection. `d79aeb6` adds checksum-verified `SettlementTaxEvidenceDatasetRevision` rows and a pricing-settlement projection that rejects non-exportable/unapproved provider evidence before settlement export. `e5a1571` adds branch/customer/HQ/system visibility policy and Pydantic boundary payloads with field profiles, denial reasons, reservation/customer/branch matching, and source evidence keys. `04690fa` binds allowed visibility decisions to `IssuePrintableDocumentAccessGrantCommand` with explicit `customer_receipt_tax_evidence` printable template kind, so customer receipt UI can request signed document access instead of composing KCP bill URLs. `24c5f40` adds typed receipt render data and a feature-local render plan for existing printable HTML/PDF pipeline; render payload includes masked identity, approval, purpose, ledger revision, field profile, reversal status, and source evidence keys while excluding provider payment/order/transaction refs. `2c0ce95` binds rendered receipt evidence to the shared `StoredPrintableDocumentArtifact` contract, validating reservation, definition key, template version, byte size, storage bucket/object key, output format, and source evidence keys before document access can point at a stored artifact. `203e179` adds a legacy KCP cash-receipt backfill command that imports approved source rows into append-only provider cash-receipt evidence with deterministic idempotency, masked registration identity references only, skip reasons for unsafe rows, and shared KCP purpose mapping reused by Kill Bill event ingestion and virtual-account notifications. `c48bbfc` adds a batched import-run handler plus internal bearer-protected `/internal/legacy-kcp-cash-receipt-backfill-imports` route wired to the Supabase cash-receipt evidence store, with per-row imported/skipped results and OpenAPI coverage. Runtime follow-up: reviewed source extractor/runbook execution for historical KCP cash-receipt rows.
`SFC-20260706-CUR-020`	Sales reporting works around timeout by splitting a selected date range into 30-day browser AJAX calls, then `combineData` adds numeric fields and concatenates reservation-id strings client-side. Chart totals and table rows can diverge from one backend dataset revision. Source chart/table SQL also recognizes revenue from mutable paid-row status/type ids, deposit-date branches, coupon joins, and payment-fee SQL; refund, partial-refund, provider closeout repair, and settlement-fee repair can therefore leave reporting stale unless they emit revenue-dataset invalidation facts. Legacy refund flips paid rows from status `1` to status `2`, while sales SQL joins status `1` rows, so refund/repair changes the source of report truth after prior snapshots. This is distinct from the tax-evidence export row: it covers operational sales dashboard/read-model authority.	`source-refs/sanmopia-admin/static/js/statistics/sales.js:625-685` (`getChartByFilter`), `source-refs/sanmopia-admin/static/js/statistics/sales.js:704-738` (`setDataTable` month chunk loop), `source-refs/sanmopia-admin/static/js/statistics/sales.js:1146-1168` (`getDatasForAMonth`), `source-refs/sanmopia-admin/static/js/statistics/sales.js:1181-1217` (`combineData`), `source-refs/sanmopia-admin/application/controllers/Statistics.php:433-498` (`getStatisticForSales`), `source-refs/sanmopia-admin/application/models/Statistics_model.php:1063-1105` (`getSalesStatisticsForMain` date grouping by deposit rows), `source-refs/sanmopia-admin/application/models/Statistics_model.php:1118-1213` (chart revenue, government support, fee, and coupon totals from paid rows and `GET_PAYMENT_FEE_RATIO`), `source-refs/sanmopia-admin/application/models/Statistics_model.php:1812-1856` and `:1912-1930` (table revenue/fee totals from paid-row joins, status `19`, work-type strings, coupons, and fee SQL), and `source-refs/sanmopia_web/application/models/Payment_model.php:383-440` (provider refund then mutable normal/voucher payment status `2`).	`business_reporting / SalesRevenueDashboardSnapshot`, `pricing_settlement / RevenueMetricDatasetRevision`, `pricing_settlement / PaymentRefundRevenueImpact`, `pricing_settlement / ProviderCloseoutRevenueRecognitionSnapshot`, `pricing_settlement / PaymentFactReportingInvalidation`, `pricing_settlement / SalesRevenueDatasetInvalidationAfterPaymentRepair`, `operator_access / ReportingScopePermission`	`Backend foundation + contract: bbb6455`; `Provider refund reporting invalidation: e038c7c`; `Provider result orchestration: 8db9942`; `Refresh queue request: fa13ef7`; `Refresh queue processor: c46382b`	Backend now has `SalesRevenueDashboardPolicy`, `SalesRevenueDashboardSnapshot`, chart buckets, table rows, recognized revenue totals, row counts, stable drilldown references, bucket grains, date-basis key, metric catalog version, revenue dataset revision key, checksum fingerprint, and Pydantic read payloads. Semantic product/channel/segment codes reject raw source status ids and UI labels; public payloads expose drilldown references but not raw reservation-id lists. Backend `e038c7c` now persists provider-refund-driven reporting invalidation instructions for sales revenue dashboards after applied, rejected, or failed provider refund results. Backend `8db9942` makes the configured provider-result handler emit those invalidations immediately after recording the paid-row transition decision. Backend `fa13ef7` queues provider-refund reporting refresh requests and marks invalidation rows `refresh_requested`. Backend `c46382b` adds the typed queue processor and success/failure row transitions. Backend `4bd75d6` binds a sales-dashboard refund-impact refresh validator that marks `sales_revenue_dashboard` refreshed only when an existing branch `sales_overview` snapshot contains the affected reservation. Remaining proof: full sales-dashboard fact recomputation, snapshot writer/read API, query adapter from payment/settlement facts, event-driven invalidation from `PaymentCloseoutRepairCase` and settlement-fee repair facts, reporting scope permission, frontend chart/table migration, and SFC-021 signed drilldown token consumption.
`SFC-20260706-CUR-021`	Sales/performance statistics cells embed raw reservation-id lists into clickable HTML and open `/reservation/historyNew/{ids}`; reservation history then posts that list back as `statisticsReservationId` and applies `where_in` filtering. No signed drilldown token, source query revision, branch-scope proof, expiry, or audit separates a reporting aggregate from operational reservation access.	`source-refs/sanmopia-admin/static/js/statistics/sales.js:780-866` (sales count drilldown cells), `source-refs/sanmopia-admin/static/js/statistics/sales.js:697-701` (`goReservationPage`), `source-refs/sanmopia-admin/static/js/statistics/performance.js:404-486` (performance count drilldown cells), `source-refs/sanmopia-admin/static/js/statistics/performance.js:835-840` (`goReservationPage`), `source-refs/sanmopia-admin/application/controllers/Reservation.php:198-200` (`historyNew` carries statistic ids), `source-refs/sanmopia-admin/static/js/reservation_status/reservation_history_new.js:236-245`, `source-refs/sanmopia-admin/application/models/Reservation_model.php:4621-4624` (`statisticsReservationId` filter)	`business_reporting / ReportingDrilldownSelectionToken`, `reservation_operations / ReservationHistoryDrilldownReadModel`, `operator_access / ReportingDrilldownAccessGrant`	`Backend foundation + contract: d5b9c80`	Backend now has `ReportingDrilldownSelectionPolicy`, HMAC-signed `ReportingDrilldownSelectionToken`, selection criteria fingerprint, public-safe selection summary, branch-scoped `ReportingDrilldownAccessGrant`, actor/scope/metric/dataset checks, expiry/consume semantics, audit event key, and Pydantic payloads that reject legacy `statisticsReservationId` extras and raw space/comma token values. Remaining proof: Supabase token/criteria persistence, SpiceDB-backed grant issuance, reservation-history token consume query, API route, audit journal persistence, and frontend table click migration from raw ids to signed token handoff.
`SFC-20260706-CUR-022`	Settlement fee classification silently treats payment rows with missing provider context as card-fee rows: service and coupon settlement detail hydration calls `getFeeData`, writes derived pay method/fee onto each row, adds those fees into branch/HQ settlement totals, and separate helper paths repeat the same 5% fallback when `PAYMENT_CONTEXT.pay_method` is absent. This can change settlement net amounts without explicit provider evidence or repair audit.	`source-refs/sanmopia-admin/application/models/Payment_model.php:418-424` (`getFeeData` hydrates detail rows), `source-refs/sanmopia-admin/application/models/Payment_model.php:445-447` (derived fee contributes to totals), `source-refs/sanmopia-admin/application/models/Payment_model.php:488-498` (coupon fee contributes to coupon/settlement totals), `source-refs/sanmopia-admin/application/models/Payment_model.php:3920-3969` (`getFeeData` provider-method fees, missing context defaults to 5%), `source-refs/sanmopia-admin/application/models/Payment_model.php:3989-4009` (`getFeeForPayMethod` missing context fallback), `source-refs/sanmopia-admin/application/models/Payment_model.php:4022-4043` (`getPayMethodAndFee` row-level fallback)	`pricing_settlement / SettlementPaymentMethodFeeEvidencePolicy`, `pricing_settlement / HistoricalPaymentFeeEvidenceBackfill`, `pricing_settlement / SettlementFeeClassificationRepairCase`	`Backend foundation`	`SettlementPaymentMethodFeeEvidencePolicy` now classifies explicit card/bank/virtual-account provider facts into immutable fee evidence with stable fingerprints, and missing context/pay method/unsupported method becomes `SettlementFeeClassificationRepairCase` instead of legacy card-fee fallback. `HistoricalPaymentFeeEvidenceBackfill` groups deterministic evidence and repair cases for historical import. Remaining proof: persist method/fee evidence with settlement dataset revision, require actor/reason for fee repair, bind settlement projections, and invalidate branch/HQ settlement read models when fee classification changes.
`SFC-20260706-CUR-023`	Branch/HQ settlement statement XLSX export is still a render-time financial authority: the controller streams by raw board id, the spreadsheet model reloads settlement detail rows, writes payment ids, deposited dates, pay methods, customer names, paid amounts, and net deposit amounts, recomputes coupon net deposit from method-specific fee math, then places an Excel `SUM` formula for total deposit. The export loader also rereads live payment rows and mutable settlement flags, including payment statuses `1/2`, `DANBEE_STATUS_FL`, provider JSON pay method, and board/detail membership/coupon/delivery flags. Refund or closeout repair after export can therefore make a downloaded statement stale unless dataset revisions, export grants, and stored artifacts are invalidated. This is distinct from `ReservationDocumentExportWorklist` selection/download flow and from `CUR-022` provider-fee evidence; exported statement line content itself is not frozen or revisioned.	`source-refs/sanmopia-admin/application/controllers/Calculate.php:568-578` (`excelDownload` reads `boardId` and streams XLSX), `source-refs/sanmopia-admin/application/models/Payment_model.php:353-524` (`loadPaymentUserToDanbeeDetail` totals current payment rows, fees, coupons, and pay methods), `source-refs/sanmopia-admin/application/models/Payment_model.php:3186-3315` (`getPaymentDataForDanbee` selects mutable paid/refunded statuses and settlement flags), `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3741-3772` (`downloadExcelFormByPaymentCentralToBranch` loads board/detail rows), `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3795-3829` (service line cells and `PRICE - FEE` net deposit), `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3834-3880` (coupon line cells and fee recomputation), and `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3893-3900` (export total as spreadsheet formula)	`document_reporting / SettlementStatementExportLineSnapshot`, `pricing_settlement / SettlementStatementDatasetRevision`, `pricing_settlement / SettlementStatementDatasetInvalidationAfterPaymentRepair`, `document_reporting / SettlementStatementExportArtifactRevocation`, `operator_access / SettlementStatementExportGrant`	`Backend foundation: e67350c`; `Provider refund reporting invalidation: e038c7c`; `Provider result orchestration: 8db9942`; `Refresh queue request: fa13ef7`; `Refresh queue processor: c46382b`; `Branch export refresh handler: 6bd851c`; `Safe refresh ids: e705d7c`	Backend now has immutable `SettlementStatementExportLineSnapshot` and `SettlementStatementDatasetRevision` freezing branch/HQ statement lines, total lines, checksums, and formula-free export cells before render. The branch settlement reconciliation export builder now renders frozen dataset cells instead of recalculating Excel totals from raw board rows. Backend `e038c7c` now persists provider-refund-driven invalidation instructions for branch/HQ settlement statements and settlement export artifacts. Backend `8db9942` makes the configured provider-result handler emit those invalidations immediately after recording the paid-row transition decision. Backend `fa13ef7` queues provider-refund reporting refresh requests and marks invalidation rows `refresh_requested`. Backend `c46382b` adds the typed queue processor and success/failure row transitions. Backend `6bd851c` adds `ProviderRefundSettlementExportRefreshHandler`: it resolves payment id to branch profile through `ReservationPaymentRecordReader`, loads the branch settlement operator dashboard, rebuilds frozen CSV/XLSX/JSON branch reconciliation exports, and runs the durable export workflow for `settlement_export_artifact` refresh requests. Backend `e705d7c` hardens workflow request ids by hashing the raw invalidation key and normalizing branch profile id into report-code-safe segments, so provider evidence is not leaked into business-report export codes. Remaining proof: bind the processor to this concrete handler in runtime composition, Supabase artifact storage proof in the stage workflow, `SettlementStatementExportGrant`, export API/read model, explicit export artifact revocation/reissue history, invalidation/reissue flow from `PaymentCloseoutRepairCase`, `SettlementLedgerReversalLine`, and settlement-fee repair facts, and frontend/admin flow wiring.
`SFC-20260706-CUR-024`	Performance dashboard service-balance exception count is computed from raw reservation status ids and `SERVICE_BALANCE_CONFIRM_FL` inside the statistics model, then the controller fills missing buckets with zero and the browser renders `NON_SERVICE_BALANCE_PRICE` as a chart series. This creates reporting/settlement state authority outside a versioned metric catalog and can drift from backend service-balance confirmation or settlement projection revisions.	`source-refs/sanmopia-admin/application/controllers/Statistics.php:306-342` (`non_service_balance_price` query and zero-fill), `source-refs/sanmopia-admin/application/models/Statistics_model.php:46-50` (`NON_SERVICE_BALANCE_PRICE` rule from status ids and `SERVICE_BALANCE_CONFIRM_FL`), `source-refs/sanmopia-admin/application/models/Statistics_model.php:165-210` (performance chart buckets grouped by created date), `source-refs/sanmopia-admin/static/js/statistics/performance.js:796-806` (browser renders `NON_SERVICE_BALANCE_PRICE`)	`business_reporting / ServiceBalanceExceptionMetricSnapshot`, `pricing_settlement / ServiceBalanceConfirmationDatasetRevision`, `operator_access / PerformanceDashboardScopeGrant`	`Backend foundation: 2fadc96`	Backend now has `ServiceBalanceExceptionMetricPolicy`, semantic `ServiceBalanceExceptionMetricStatusPolicy`, frozen facts, daily zero-filled buckets, dataset revision key, metric version, date-basis key, and checksum fingerprint. Raw numeric source status ids are rejected at the domain boundary. Remaining proof: Supabase snapshot persistence, Pydantic/API contracts, dashboard read model, `PerformanceDashboardScopeGrant`, and frontend chart migration.
`SFC-20260706-CUR-025`	Performance funnel and rebooking metrics are assembled from independent controller/model switches and browser math: source runs separate queries for default service-day, unassigned caregiver, consulting-status, change-status, rebook, and newbook buckets; consulting/change metrics read `RESERVATION_CHANGE_LOG.BEFORE_DATA` string fragments; newbook/rebook use raw reservation flags/count subqueries; the datatable recomputes rebooking ratio in JavaScript from returned count groups. This is distinct from `CUR-024`, which covers only the service-balance exception metric.	`source-refs/sanmopia-admin/application/controllers/Statistics.php:294-323` (separate performance metric queries), `source-refs/sanmopia-admin/application/controllers/Statistics.php:327-368` (zero-fill and max-count derivation), `source-refs/sanmopia-admin/application/models/Statistics_model.php:24-62` (`SERVICE_DAY_DEFAULT`, `NON_MANAGER`, `STATUS_CONSULTING`, `STATUS_CHANGE`, `REBOOK`, `NEWBOOK` rules), `source-refs/sanmopia-admin/application/models/Statistics_model.php:215-230` (change-log string matching and raw filter assembly), `source-refs/sanmopia-admin/application/models/Statistics_model.php:1000-1031` (extension/rebook counts), `source-refs/sanmopia-admin/static/js/statistics/performance.js:646-675` (browser rebook ratio calculation), `source-refs/sanmopia-admin/static/js/statistics/performance.js:796-809` (browser chart series assembly)	`business_reporting / BusinessPerformanceFunnelSnapshot`, `business_reporting / RebookingMetricDatasetRevision`, `operator_access / PerformanceDashboardScopeGrant`	`Backend foundation + contract: 550f3c7`	Backend now has `BusinessPerformanceFunnelPolicy`, `BusinessPerformanceMetricCatalog`, normalized `BusinessPerformanceFunnelFact`, daily zero-filled `BusinessPerformanceFunnelBucket`, `RebookingMetricComponentBucket`, backend-owned rebooking numerator/denominator/ratio, date-basis code, metric catalog fingerprint, dataset revision key, checksum, and strict Pydantic payloads. Contracts reject source metric labels and table shapes such as `STATUS_CHANGE`, `STATUS_CONSULTING`, `REBOOK_COUNT`, `ALL_COUNT_1`, and raw source status ids/service labels. Remaining proof: Supabase snapshot persistence, adapter from reservation/payment/continuation/status-transition facts, `PerformanceDashboardScopeGrant`, API/read model, and frontend chart/table migration without JavaScript ratio math or raw reservation flag inference.
`SFC-20260706-CUR-026`	Statistics report tables use the browser DataTables contract as query authority: controller reads posted draw/start/length/order/search, maps column indexes to hardcoded report columns, and routes sales/performance/user/branch table types; the generic datatable helper selects requested columns, applies browser order/search across mapped DB columns, counts filtered rows, and limits by posted offset. Sales and performance table paths also load all aggregate rows, slice them in PHP, and build all-branch totals from the full mutable result set. This is distinct from `CUR-020` chart chunking and `CUR-025` metric definitions; it covers report table query, sorting, filtering, pagination, and totals authority.	`source-refs/sanmopia-admin/application/controllers/Statistics.php:112-123` (DataTables request fields), `source-refs/sanmopia-admin/application/controllers/Statistics.php:125-168` (hardcoded report table columns), `source-refs/sanmopia-admin/application/controllers/Statistics.php:216-241` (posted order/search mapping), `source-refs/sanmopia-admin/application/models/Datatable_model.php:32-47` (browser-selected columns), `source-refs/sanmopia-admin/application/models/Datatable_model.php:57-86` (browser order/search over mapped columns), `source-refs/sanmopia-admin/application/models/Datatable_model.php:94-103` (count and limit), `source-refs/sanmopia-admin/application/models/Statistics_model.php:263-269` (performance all-row load then PHP slice), `source-refs/sanmopia-admin/application/models/Statistics_model.php:345-520` (performance all-branch totals), `source-refs/sanmopia-admin/application/models/Statistics_model.php:1278-1291` (sales all-row load then PHP slice), `source-refs/sanmopia-admin/application/models/Statistics_model.php:1293-1575` (sales all-branch totals)	`business_reporting / OperatorReportTableSnapshot`, `business_reporting / ReportTableQueryPolicy`, `operator_access / ReportTableReadGrant`	`Backend foundation + contract: d95fdd7`	Backend now has `OperatorReportTableColumnCatalog`, typed sort/filter/page intents, `ReportTableReadGrant`, `ReportTableQueryPolicy`, `OperatorReportTableSnapshot`, totals-row policy, filtered/total row counts, page cursor, dataset revision key, checksum fingerprint, and Pydantic payloads that reject DataTables transport extras (`draw`, `order`, `search`) and browser column indexes. Remaining proof: Supabase snapshot/query persistence, SQL adapter from report datasets, SpiceDB-backed read grants, API route, export-artifact compatibility, and frontend table migration to typed query intents.
`SFC-20260706-CUR-027`	Visitor/user/branch access statistics derive engagement, demographic, and access-environment metrics from controller/model/browser fragments: controller merges chart/table payloads for `userConnect` and `user`; model hardcodes age bands, raw reservation status ids, browser/source `TYPE` labels, Edge-to-Internet-Explorer normalization, Korean pet type strings, duplicate-user subtraction, and branch exclusions; browser code computes percentages and maps pet counts into visible dog/cat slots. This is distinct from `CUR-006` telemetry capture and `CUR-026` table query contract; it covers operator-visible engagement metric definitions and totals authority.	`source-refs/sanmopia-admin/application/controllers/Statistics.php:380-397` (`getStatisticForUserConnect` chart/table payload mix), `source-refs/sanmopia-admin/application/controllers/Statistics.php:400-415` (`getStatisticForUser` age and pet payloads), `source-refs/sanmopia-admin/application/models/Statistics_model.php:2114-2128` (branch access browser-type rollup and Edge fallback), `source-refs/sanmopia-admin/application/models/Statistics_model.php:2194-2232` (user login-type age/device buckets), `source-refs/sanmopia-admin/application/models/Statistics_model.php:2234-2258` (age-band reservation status buckets), `source-refs/sanmopia-admin/application/models/Statistics_model.php:2314-2365` (pet-type string categorization), `source-refs/sanmopia-admin/application/models/Statistics_model.php:2376-2447` (age bucket rollups), `source-refs/sanmopia-admin/application/models/Statistics_model.php:2495-2527` (duplicate-user subtraction for new-user metric), `source-refs/sanmopia-admin/static/js/statistics/visitor.js:445-546` (browser device ratios and chart percentages), `source-refs/sanmopia-admin/static/js/statistics/user.js:593-621` (browser pet count/ratio rendering)	`business_reporting / MemberActivityAnalyticsSnapshot`, `business_reporting / BranchAccessAnalyticsSnapshot`, `business_reporting / EngagementMetricCatalog`, `operator_access / EngagementReportScopeGrant`	`Backend foundation + contract: f5e24a1`	Backend now has `EngagementAnalyticsPolicy`, `AgeBandCatalog`, `SourceDeviceNormalizationPolicy`, `PetTaxonomyMappingPolicy`, `EngagementMetricCatalog`, `BranchAccessAnalyticsSnapshot`, `MemberActivityAnalyticsSnapshot`, checksum fingerprints, duplicate-user counting, excluded-branch selection, backend-owned integer ratio policy, and strict Pydantic payloads. Public payloads expose normalized age/device/lifecycle/pet taxonomy buckets and reject legacy source labels/count fields such as `source_device_label`, `source_pet_label`, `DOG_COUNT`, `CAT_COUNT`, and `AGE_1_COUNT`. Remaining proof: Supabase snapshot persistence, source-data adapter from visitor/user facts, `EngagementReportScopeGrant`, API routes/read model, and frontend chart/table migration without browser-side percentage math or pet/device relabeling.
`SFC-20260706-CUR-028`	Reservation history list XLSX export is a browser-selected artifact with raw reservation ids in a query string: the history table checkbox stores `data-index`, download JS joins checked ids, controller explodes `reservationArray`, and spreadsheet rendering reloads current reservation/payment/address/caregiver rows before streaming PII and payment dates directly to `php://output`. This is distinct from `CUR-021` report drilldown tokens and data-room document bundles; it covers operator reservation-list export authority, privacy scope, and artifact audit.	`source-refs/sanmopia-admin/application/views/reservation_status/reservation_history_new.php:127` (download button), `source-refs/sanmopia-admin/static/js/reservation_status/reservation_history_new.js:357` (row checkbox `data-index`), `source-refs/sanmopia-admin/static/js/reservation_status/reservation_history_new.js:708-724` (`downloadReservation` builds raw id query), `source-refs/sanmopia-admin/application/controllers/Reservation.php:1727-1736` (`excelDownloadForReservaitonHistoryNew` reads `reservationArray`), `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4604-4615` (`excelDownload` loads template and timestamp filename), `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4616-4647` (mutable reservation/payment/address/caregiver query), `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4652-4665` (PII/payment-date cells), `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4668-4675` (direct XLSX stream)	`document_reporting / ReservationHistoryExportSelectionCriteria`, `document_reporting / ReservationHistoryExportDatasetSnapshot`, `document_reporting / ReservationHistoryExportArtifactRequest`, `operator_access / ReservationHistoryExportGrant`	`Backend foundation + contract: 483593d`	Backend now has `ReservationHistoryExportSelectionCriteria`, `ReservationHistoryExportGrant`, normalized `ReservationHistoryExportSourceRow`, frozen `ReservationHistoryExportLineSnapshot`, `ReservationHistoryExportDatasetSnapshot`, private `ReservationHistoryExportArtifactRequest`, content fingerprint, expected filter/query revision, payment-date source revision, PII mask profile, retention policy key, and strict Pydantic payloads. Contracts reject browser query-string ids (`reservationArray`, `123,456`), raw numeric reservation ids, raw phone/address values, and legacy spreadsheet fields such as `USER_CELLPHONE`, `ADDRESS`, and `BIRTH_DT`. Remaining proof: Supabase selection/dataset/artifact persistence, source-row adapter from reservation/payment/address/caregiver projections, SpiceDB/RLS grant issuance, async XLSX/HTML renderer, signed storage download grant, export audit ledger, API route, and admin UI migration from checked raw ids to typed export request.

2026-07-10 source-dig refinement for SFC-20260706-CUR-020: source sales/statistics screens set the default reporting window in browser state to previous month, post those dates directly to chart/table endpoints, split data-table reads into 30-day chunks, then merge numeric fields and raw reservation-id strings client-side. PHP sales chart/table logic separately classifies offline/manual revenue by raw reservation status 19, joins only paid payment rows (PAYMENT_STATUS_LIST_ID_FK = 1), excludes raw status ids [9,14,17,18] and branch id 37, and has a legacy fixed March 2020 table query. Evidence: source-refs/sanmopia-admin/static/js/statistics/sales.js:20-25, source-refs/sanmopia-admin/static/js/statistics/sales.js:625-685, source-refs/sanmopia-admin/static/js/statistics/sales.js:704-738, source-refs/sanmopia-admin/static/js/statistics/sales.js:1146-1217, source-refs/sanmopia-admin/application/controllers/Statistics.php:112-123, source-refs/sanmopia-admin/application/controllers/Statistics.php:433-498, source-refs/sanmopia-admin/application/models/Statistics_model.php:1063-1213, source-refs/sanmopia-admin/application/models/Statistics_model.php:1812-1930, and source-refs/sanmopia-admin/application/models/Statistics_model.php:2612-2627. Target refinements: business_reporting / SalesReportingDateWindowPolicy, business_reporting / RevenueRecognitionStatusCatalog, business_reporting / SalesRevenueDatasetRevision, and operator_access / SalesReportingScopeGrant. Backend authority must freeze the date window, revenue date basis, recognized/offline/manual channel split, payment fact revision, status catalog revision, branch-scope grant, and dataset checksum before dashboards, drilldowns, or settlement-facing revenue exports render. Browser defaults, raw ids, status math, and PHP fixed-date test queries remain migration evidence only.
2026-07-10 runtime binding update for SFC-20260706-CUR-023: backend 1a6a7cc now wires QueueWorkloadKind.PROVIDER_REFUND_REPORTING_REFRESH to SupabaseProviderRefundReportingProjectionRefreshProcessor with the concrete ProviderRefundSettlementExportRefreshHandler. The older remaining-proof note about runtime composition binding is superseded. Backend follow-ups now prove reversal lines, branch/HQ statement and operator-board refresh validation, sales-dashboard snapshot coverage validation, and workspace-domain artifact grant revocation. Remaining proof is staged Supabase artifact storage, export grants/read APIs, persisted artifact revocation/reissue lineage, full sales-dashboard recomputation/read APIs, and repair-triggered invalidation.
2026-07-14 dataset-lineage repair for SFC-20260706-CUR-023: backend b3d3dc1 now persists and rehydrates the branch reconciliation export’s dataset_revision_key and SHA-256 dataset_revision_fingerprint through its frozen business-report snapshot. Migration enforcement allows legacy rows with both fields null, or requires both a nonblank key and a lowercase 64-hex fingerprint; a partial pair is rejected. Focused adapter and migration checks pass, including isolated PostgreSQL acceptance of the null pair and exact pair plus rejection of partial and invalid-digest rows. This closes lineage loss in that adapter. It does not prove stage Storage, signed export grants, artifact revocation/reissue, repair-triggered invalidation, or admin UI wiring.
2026-07-10 source-mining refinement for SFC-20260706-CUR-003: the initial-consult workbook is also a financial consumer, not only a free-text layout. The spreadsheet builder loads a fixed consultation template, writes current government/customer/service amounts, chooses either mutable CUSTOM_SERVICE_BALANCE_PRICE or the current PRICE_TABLE['leftPrice'], and parses Korean display labels from additionalServicePriceList into fixed workbook cells. Evidence: source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3500-3509 (template load), :3655-3673 (current service-balance selection), and :3676-3711 (label-parsed add-service amounts). Modern invariant: ReservationIntakeDocumentProjection and ReservationChargeDocumentSnapshot must consume frozen charge, service-balance, and add-option revisions with typed component codes and integer amounts; document rendering must not read the current custom-balance flag, mutable price table, or Korean labels as financial authority. Status remains Partial: backend a31229f covers free-text layout policy, while frozen financial render inputs, artifact invalidation/reissue after charge or refund repair, and historical document-input backfill remain open.
2026-07-10 source-mining refinement for SFC-20260706-CUR-022, SFC-20260706-CUR-023, and SFC-20260708-CUR-088: legacy settlement fee rounding diverges across browser, PHP detail, and XLSX consumers. The browser applies Math.ceil for explicit card, account-transfer, and virtual-account methods but uses an unrounded five-percent fallback when method evidence is absent; PHP settlement detail and coupon export paths multiply rates without that ceiling. Evidence: source-refs/sanmopia-admin/static/js/calculate_detail.js:854-885, source-refs/sanmopia-admin/application/models/Payment_model.php:3920-3969, and source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3869-3880. Modern invariant: SettlementPaymentMethodFeeEvidencePolicy must freeze the method, rate, integer-KRW rounding mode, per-line versus aggregate rounding scope, computed fee, policy revision, and evidence revision. Data-room UI and SettlementStatementDatasetRevision exports must consume that same frozen integer instead of recomputing it. Status remains Partial: fee-policy and frozen export-line foundations exist, but source-rounding parity, historical backfill, and binding every detail/data-room/export consumer to one fee fact remain unproven.
2026-07-10 source-mining refinement for existing document delivery owners ReservationDocumentDelivery, DocumentDeliveryAttempt, and DocumentRecipientAuthority: scheduled system delivery and manual CLI resend capture the Gmail result but do not inspect it before recording sent-state flags, creating customer notifications, and deleting temporary attachments. Manual target/start-document paths also copy every generated attachment to a hardcoded BCC address outside reservation recipient facts. Evidence: source-refs/sanmopia-admin/application/controllers/cli/ReservationDocument.php:104-129, :203-225, :337-363, and :430-455 (unchecked delivery result followed by sent-state/notification/temp-file effects), plus :229-243 and :620-692 (manual delivery with hardcoded BCC). Actors: scheduled system worker and explicitly invoked manual document operator. Backend rule: issue a versioned recipient-authority snapshot for every To/CC/BCC recipient and purpose, persist provider acceptance/failure/unknown outcome before changing delivery state, keep artifact lineage available for retry/reconciliation, and create customer inbox readiness independently from email success. Modern target: DocumentDeliveryAttempt, DocumentRecipientAuthority, DocumentDeliveryResultReconciliation, and StoredPrintableDocumentArtifact. Status remains Partial: document readiness/artifact/delivery policy foundations exist, but scheduled/manual worker binding, recipient-policy persistence, provider-result history, retry/reconciliation, and removal of hardcoded BCC delivery remain unproven.
2026-07-10 source-mining correction for SFC-20260706-CUR-023 and SFC-20260706-CUR-044: settlement XLSX export has neither typed collection selection nor actor-bound board scope. Calculate requires login only, then accepts query excelType and boardId; the spreadsheet function never uses excelType, always treats the id as DANBEE_PAYMENT_BOARD_ID_PK, loads a fixed template, and rereads that Danbee board without a branch/HQ grant check. Evidence: source-refs/sanmopia-admin/application/controllers/Calculate.php:4-10 and :568-578, plus source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3741-3772. Actor: any authenticated branch or headquarters session reaching the route. Backend rule: derive artifact kind and canonical collection from a typed settlement lookup, resolve board/statement revision server-side, authorize actor plus participant branch before dataset read, and bind build/download to one SettlementStatementExportGrant; query type or numeric board id must never select collection or scope. Modern target: SettlementDataRoomArtifactRequest, SettlementStatementDatasetRevision, SettlementStatementExportGrant, and SettlementArtifactBuildRunLedger. Status remains Partial: frozen export-line and refund-refresh foundations exist, while actor-scoped export API/grant persistence, typed artifact-kind binding, stage storage proof, and legacy route disable/adapter work remain open.
2026-07-10 source-mining refinement for SFC-20260706-CUR-028 and SFC-20260706-CUR-035: reservation-history XLSX receipt dates use a mismatched payment predicate. The subquery tests normal-payment paid status while testing voucher payment type, prefers voucher deposited date through IFNULL, and falls back to reservation creation time. Outer normal/voucher joins can produce duplicate rows, then GROUP BY reservation collapses them before receipt and service-payment dates are written to the workbook. Evidence: source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4623-4628, :4642-4649, and :4664-4665. Actor: branch/HQ operator exporting selected reservation-history rows. Backend rule: select receipt date from typed payment purpose plus terminal collection status at an explicit payment-fact revision, choose a deterministic fact when multiple attempts exist, and emit a semantic missing/fallback reason instead of silently substituting booking creation time or SQL group order. Modern target: ReservationHistoryPaymentFactSummaryProjection, ReservationHistoryReceiptDateSelectionPolicy, and ReservationHistoryExportDatasetSnapshot. Status remains Backend foundation / adapter partial: summary and frozen export-dataset contracts exist, but payment-fact source adapter parity, deterministic receipt-date selection, historical discrepancy backfill, and runtime XLSX binding remain unproven.

2026-07-06 Backend Migration Follow-Up

2026-07-09 persistent legacy-gap mining refresh

This pass did not create new feature ids because the affected areas already have named owners below. The added value is status/proof tightening plus precise source evidence that must stay as backend migration evidence, not UI authority.

Area	Existing owner row(s)	Implementation/proof status after mining	Additional source evidence
Family/proxy booking, payer, notification, and document authority	High-level family authority rows `P0 / Family, proxy payer, contact, refund, and document authority`, `ReservationPartyAuthoritySnapshot`, and `DocumentRecipientAuthority`	`Partial`. Contract/domain naming exists, but booking, payment, refund, receipt, document, and notification commands still need one persisted `ReservationPartyAuthoritySnapshot` and grant projection. Mother-facing or operator UI must not infer authority from relation text, phone, reservation owner id, branch phone special cases, or copied mutable reservation/user rows.	`source-refs/sanmopia_web/application/views/service/step1.php:90-213` (mother/contact/relation inputs), `source-refs/sanmopia_web/application/controllers/api/Service.php:67-83` (relation/contact copied into user profile), `source-refs/sanmopia_web/application/controllers/api/Payment.php:89-113` (owner/payment-state gate plus `PRICE_TABLE` amount), `source-refs/sanmopia_web/application/models/Payment_model.php:101-225` (downpayment rows from live reservation price table), `source-refs/sanmopia_web/application/models/Payment_model.php:570-704` (mother/branch notification routing), `source-refs/sanmopia_web/application/controllers/MyReservation.php:366-370` and `source-refs/sanmopia_web/application/controllers/Notification.php:21-25` (document token issuance to the logged-in user).
Document/archive download, scheduled delivery, and bundle grants	`SFC-20260708-CUR-097`, document rows `P1 / StoredPrintableDocumentArtifact`, `PrintableDocumentAccessGrant`, `DocumentCenterProjection`, and `ReservationDocumentDelivery`	`Partial`. Document-center projection/API is represented, but signed-storage handoff, customer token replacement, scheduled-mail delivery attempts, ZIP/bundle policy, and live-render guard remain proof gaps. UI must render backend handoff descriptors only; it must not compose numeric document ids, token query strings, bundle members, or render request codes.	`source-refs/sanmopia_web/application/models/User_model.php:461-489` (two-hour `documentDownload` token delete/recreate/read), `source-refs/sanmopia-admin/application/controllers/cli/ReservationDocument.php:104-129`, `:203-225`, and `:337-363` (scheduled PDF attachment generation, mail send, temp-file delete, send-status insert), `source-refs/sanmopia-admin/application/controllers/DataRoom.php:311-376` (service-type document bundle composition and direct export call).
Caregiver matching candidate selection and assignment proof	`SFC-20260708-CUR-089`, `CaregiverCandidateOrderingPolicy`, `CaregiverCandidateSelectionToken`, and payout invalidation rows	`Partial`. Candidate snapshots/order policy exist, and browser authority field rejection is noted, but branch/HQ assignment E2E still needs backend-issued selection tokens, score/distance/transit evidence revisions, expected roster revision, override reason, conflict acknowledgement, and payout/document invalidation proof.	`source-refs/sanmopia-admin/application/models/Matching_model.php:62-176` (score views, schedule SQL, pet exclusion, random tie, distance calculation/sort), `source-refs/sanmopia-admin/application/controllers/ajax/Reservation.php:36-65` (raw candidate id, posted `fmanager-score`, `0점` short-circuit, distance/transit load), `source-refs/sanmopia-admin/application/controllers/ajax/Reservation.php:180-208` (raw assignment history read).
Provider browser handoff and provider-success/local-write-failure compensation	`PaymentProviderHandoffSession`, `PaymentProviderApprovalRequest`, `PaymentProviderCloseoutCompensationSaga`, `CustomerPaymentInstruction`, `PaymentProviderAttempt`, `CompensationRefundIntent`, `ProviderRefundExecutionAttempt`, `PaymentCloseoutRepairCase`, `ProviderRefundResultEvent`, and `PaymentCloseoutReportingInvalidation`	`Backend foundation / Handoff + attempt + compensation intent + repair planning + execution/result-recording persistence partial`. Provider amount and frozen pre-registration guards existed; 2026-07-09 backend follow-ups add `PaymentProviderHandoffSession`, handoff Pydantic payloads, `PaymentProviderHandoffSessionStore`, `SupabasePaymentProviderHandoffSessionStore`, and service-role-only table `sanmopia_payment_provider_handoff_sessions` with RLS enabled. The session freezes amount, allowed method set, selected method, provider route, backend-owned relative return path, expected payment revision, expiry, idempotency key, source evidence, and handoff fingerprint, and rejects browser-controlled provider payload. The same follow-up adds `PaymentProviderAttempt`, `PaymentProviderAttemptStore`, provider-attempt Pydantic payload, `SupabasePaymentProviderAttemptStore`, and service-role-only table `sanmopia_payment_provider_attempts`. The attempt record captures handoff session/fingerprint, reservation/payment refs, purpose, amount, method, provider route/operation/request/transaction, provider result state, closeout write state, timestamps, failure reason, compensation intent, source evidence, `requires_compensation_refund`, and attempt fingerprint. Domain and DB reject browser-reported amount authority; stage DB migrations verified RLS true, anon/authenticated revoked, service_role select/insert/update only, and compensation flag must match provider-accepted failed closeout. 2026-07-09 compensation follow-up adds `PaymentProviderCloseoutCompensationPolicy`, `PaymentProviderCloseoutCompensationHandler`, Pydantic intent payload, `SupabasePaymentProviderCloseoutCompensationIntentStore`, and service-role-only `sanmopia_payment_provider_closeout_compensation_intents`; a rollback stage insert proved canonical KillBill refund-intent rows satisfy constraints without leaving test data. 2026-07-09 runtime follow-up reads the latest `PaymentProviderHandoffSession` during KillBill paid-webhook ingestion, persists `PaymentProviderAttempt` with `workflow_start_failed` when local workflow start fails after provider success, and creates `PaymentProviderCloseoutCompensationIntent` through the runtime app wiring. Current repair follow-up exposes token-gated `/internal/payment-refund-repairs/provider-refund-plans`, persists the repair plan through `PaymentRefundRepairHandler` plus `SupabasePaymentRefundRepairPlanStore`, exposes token-gated `/internal/payment-refund-repairs/provider-refund-executions`, calls `PaymentGatewayClient.refund`, persists execution attempts through `SupabasePaymentRefundRepairExecutionAttemptStore`, and records accepted/rejected repair execution results through `ProviderRefundResultFromLedgerHandler`. Remaining gaps: runtime KillBill approval request binding, retry/result-history hardening, operator repair/read projection, and revenue/settlement read-model invalidation proof after compensated or repaired closeout. Legacy `Kcppayment::refund()` can issue a KCP `STSC` cancel and still return a local failure payload, so modern repair must model provider-refund execution attempt, provider-result certainty, local closeout outcome, idempotency, and reporting invalidation as separate facts. UI/PHP must not decide payment amount, allowed method, return route, provider handoff params, compensation success, or repair state.	`source-refs/sanmopia_web/application/views/item/kcp/order_info_form.php:35-75` (visible KCP order fields including amount, method, return URL, user/order refs), `source-refs/sanmopia_web/application/views/item/kcp/pay_form.php:4-24` (provider response handoff fields), `source-refs/sanmopia_web/static/js/lib/kcp/approval_key.js:55-65` (approval-key query built from browser form), `source-refs/sanmopia_web/static/js/reservation_payment.js:120-183`, `source-refs/sanmopia_web/static/js/pre_reservation_payment.js:41-117`, and `source-refs/sanmopia_web/static/js/mypage/reservation_changePayment.js:43-89` (browser amount/method/return-route handoff), `source-refs/sanmopia_web/application/controllers/api/Payment.php:13-58` (approval route reads `good_mny` and `Ret_URL` from browser query despite server-session warning), `source-refs/sanmopia_web/application/controllers/api/Payment.php:160-180`, `:215-218`, `:272-303`, `:388-413`, `:553-591`, and `:720-762` (provider-first then local write then inline refund), `source-refs/sanmopia_web/application/libraries/Kcppayment.php:418-437` (`refund()` always returns `status => false` after KCP cancel request), and `source-refs/sanmopia_web/application/libraries/Kcppayment.php:447-475` (manual KCP full cancel command).
Payment record closeout overwrite guard	`RecordProviderPaymentCloseoutCommand`, `RecordPreReservationPaymentCloseoutCommand`, `PaymentProviderAttempt`, `OperatorPaymentFactEditCommand`, `RecordReservationPaymentReceiptCommand`, `PaymentCloseoutRepairCase`, and `ProviderRefundResultEvent`	`Backend guard partial / manual receipt plus provider stale-handoff guard implemented`. Legacy normal and pre-reservation customer closeout build mutable row payloads, then update an existing payment row by reservation plus payment type, so repeated provider/browser closeout can overwrite paid/refunded/settlement-bound facts. Modern backend now treats manual reservation receipts as new payment facts at expected revision `0` only, persists/returns `payment_fact_revision`, rejects stale existing rows with `stale expected_payment_revision`, and sends any existing payment fact mutation through `OperatorPaymentFactEditCommand`, which already requires actor, reason, idempotency key, immutable amount snapshot, expected revision, refunded guard, settlement-lock guard, audit, and projection invalidation. Backend `7eaef19` also carries `payment_fact_revision` into the Kill Bill paid-webhook payment snapshot; provider accepted/local workflow-start failure attempts compare the latest `PaymentProviderHandoffSession.expected_payment_revision` to the current payment fact revision, keep compensation-refund intent eligible, and mark `stale_payment_provider_handoff_revision` plus `payment_fact_revision:expected::actual:` source evidence when the browser/provider handoff used old payment facts. Provider closeout commands still need `provider_attempt_id`, `handoff_session_id`, `payment_purpose`, reservation/pre-reservation id, payment type, backend charge snapshot id, provider transaction id, method, raw provider result artifact id, expected payment revision, idempotency key, occurred-at timestamp, and repair-case id when replaying. Remaining runtime work: actual provider closeout mutation must persist closeout facts with provider attempt lineage in the same revision/repair model and bind provider refund result ingestion.	`source-refs/sanmopia_web/application/models/Payment_model.php:50-75` (customer closeout update path by reservation/payment type), `source-refs/sanmopia_web/application/models/Payment_model.php:198-226` (normal payment-row payload and status/deposited fields), `source-refs/sanmopia_web/application/models/Payment_model.php:794-819` (pre-reservation payment-row payload and status/deposited fields), `source-refs/sanmopia_web/application/controllers/api/Payment.php:111-180` (normal provider result then local write/refund-on-failure), and `source-refs/sanmopia_web/application/controllers/api/Payment.php:537-572` (pre-reservation zero/provider closeout then local write/refund-on-failure).
Payment closeout-triggered notification/document activation	`PaymentCloseoutNotificationOutbox`, `ReservationDocumentReadinessLifecycle`, `ReservationDocumentReadinessRevocationAfterPaymentRepair`, `DocumentCenterProjectionInvalidationAfterRefund`, `PaymentCommunicationWorkflow`, and `DocumentRecipientAuthority`	`Partial; trigger ordering and revocation not fully owned`. Legacy downpayment closeout creates promotion and reservation-document notifications inline, while document screens mint a two-hour `documentDownload` token and the download API only rechecks token plus reservation ownership before rendering/downloading. Controllers also send immediate customer/branch Aligo or SMS notices after the DB transaction and suppress standard completion notices for virtual-account flows. Modern closeout should emit ordered outbox facts after payment record commit and document readiness should derive from backend payment closeout, not controller side effects. Refund, paid-row repair, closeout replay, or party-authority repair must invalidate or revoke document readiness, document-center projection rows, and issued access grants before new artifacts or handoffs are exposed. Required facts: `PaymentFactCommitted`, `VirtualAccountInstructionIssued`, `CustomerPaymentCompletionNoticeRequested`, `BranchPaymentCompletionNoticeRequested`, `ReservationDocumentReadinessActivated`, `ReservationDocumentReadinessRevoked`, `DocumentCenterProjectionInvalidated`, recipient authority snapshot, branch recipient snapshot, and branch-special-recipient routing proof.	`source-refs/sanmopia_web/application/models/Payment_model.php:126-138` (inline `MOMFIRST_PROMOTION` and `RESERVE_DOCUMENT` notification creation), `source-refs/sanmopia_web/application/models/User_model.php:461-489` (document token replacement and two-hour lookup), `source-refs/sanmopia_web/application/controllers/MyReservation.php:365-370` and `source-refs/sanmopia_web/application/controllers/Notification.php:19-25` (logged-in document-token issuance paths), `source-refs/sanmopia_web/application/controllers/api/ReservationDocument.php:21-39` (token plus reservation ownership download guard), `source-refs/sanmopia_web/application/views/mypage/reservation_document.php:118-137` (browser-composed document download URL), `source-refs/sanmopia_web/application/controllers/api/Payment.php:126-157` (virtual-account instruction notice before local closeout), `source-refs/sanmopia_web/application/controllers/api/Payment.php:182-214` (normal downpayment customer/branch completion notices and branch-id special recipient), `source-refs/sanmopia_web/application/controllers/api/Payment.php:598-645` (pre-reservation customer/branch completion notices and branch-id special recipient), and `source-refs/sanmopia_web/application/controllers/api/Payment.php:740-755` (change-payment customer/branch completion notices).
Payment closeout occurrence-ledger materialization	`MaterializeReservationServiceOccurrenceLedgerCommand`, `PaymentCloseoutOccurrenceLedgerGuard`, `ServiceOccurrenceLedger`, `ReservationPaymentWorkflow`, `ReservationDateMaterializationPolicy`, and `SettlementContinuationPrerequisite`	`Partial; customer payment closeout trigger still mapped as source evidence only`. Legacy successful payment calls `RESERVATION_DATE_INSERT_FN`, making service occurrence materialization a hidden payment side effect. The same routine also runs from service voucher/date edits and admin service-period saves, so modern closeout must validate or idempotently create occurrence ledger facts with a source-attributed cause (`payment_closeout`, `service_period_change`, or `admin_repair`), expected reservation/service-period revision, service calendar policy fingerprint, payment closeout event id, idempotency key, and resulting occurrence-ledger revision before settlement, payout, calendar, or report readiness changes.	`source-refs/sanmopia_web/application/models/Payment_model.php:276-278` (payment closeout triggers reservation-date insertion function), `source-refs/sanmopia_web/application/controllers/api/Payment.php:160-180` (normal local closeout call site), `source-refs/sanmopia_web/application/models/Reservation_model.php:510` and `:539` (service voucher insert/update also call the routine), `source-refs/sanmopia_web/application/models/Reservation_model.php:3170-3173` and `source-refs/sanmopia_web/application/controllers/api/Reservation.php:439-444` (service-period edit wrapper), `source-refs/sanmopia-admin/application/controllers/Reservation.php:1080-1088` (admin pre-reservation service save calls the routine), and `source-refs/sanmopia-admin/application/models/Reservation_model.php:2017` and `:5196` (admin service/payment save and admin add-reservation paths call the routine).
Pre-reservation conversion payment compatibility	`PreReservationConversionStateProjection`, `PreReservationConversionPaymentCompatibility`, `ReservationPriceVersionAdjustment`, and `CancellationRefundEligibility`	`Partial; exact compatibility flag not yet isolated`. Source `PRE_CONVERT_FL` changes cancellation, detail display, and price-version behavior after pre-reservation converts into a reservation. Modern backend must freeze conversion state, payment lineage, prior pre-reservation credits/coupons, and refund/price-version compatibility instead of letting UI/status queries infer it from raw flags.	`source-refs/sanmopia_web/application/models/Payment_model.php:108-114`, `source-refs/sanmopia_web/application/models/Reservation_model.php:1537-1545`, and `source-refs/sanmopia-admin/application/models/Reservation_model.php:5677-5684`.
Stopped voucher settlement seed backfill	`StoppedReservationSettlementSeedBackfillCommand`, `SettlementStatementSeedDecision`, `ReservationCancellationSettlementImpact`, `SettlementSeedRepairAudit`, and `ReservationFinancialLifecycleSeedRepair`	`Mapped; backfill command missing`. Normal legacy status save opens branch/HQ settlement rows from raw reservation status, while a separate admin repair path finds stopped voucher reservations missing those rows and would seed type `1/2` settlement rows by reservation id only. Modern backfill must be a backend repair command with expected reservation revision, frozen stopped-voucher eligibility, cancellation/refund impact proof, payment fact revision, idempotent seed decision, actor scope, and append-only audit before branch/HQ statement projections or artifact exports see repaired data. UI/admin/PHP must not infer settlement readiness from raw status `13`, missing `PAYMENT_ADMIN_BRANCH_TB` rows, or mutable payment-row refund flags.	`source-refs/sanmopia-admin/application/models/Reservation_model.php:1803-1820` (status transition opens service-balance, caregiver payout, and branch/HQ settlement seed paths), `source-refs/sanmopia-admin/application/models/Payment_model.php:2619-2653` (raw branch/HQ settlement seed rows `PAYMENT_TYPE_LIST_ID_FK` `1/2`), `source-refs/sanmopia-admin/application/controllers/Administrator.php:203-210` (repair endpoint), and `source-refs/sanmopia-admin/application/models/Payment_model.php:4241-4262` (stopped voucher missing-seed scan and commented row insertion).
Virtual-account issue, deposit callback, dedupe, and paid-after-expired race	`VirtualAccountPaymentLifecycle`, `PaymentVirtualAccountInstructionPayload`, `PaymentVirtualAccountInstructionSnapshot`, `PaymentProviderNotificationDeduplication`, and `VirtualAccountDepositReservationTransition`	`Backend foundation / Persistence partial`. Typed lifecycle/domain exists, and 2026-07-09 backend follow-up now persists `VirtualAccountPaymentLifecycleDecision` rows in Supabase through a service-role-only, RLS-enabled table. Runtime notification id dedupe, amount-match proof, cancel/non-`TX00` lifecycle facts, reservation-transition decision persistence, and expired-after-paid race handling still need proof. Legacy code matches only `order_no`/`tno`, treats already-paid rows as success, stores raw KCP JSON, and can mutate `입금대기 -> 예약` or `사전예약대기 -> 사전예약` from a late callback without a frozen expiry decision.	`source-refs/sanmopia_web/application/controllers/api/Kcp.php:18-103` (IP check, raw POST log, non-`TX00`/cancel ack, `noti_id` read but not persisted as idempotency key), `source-refs/sanmopia_web/application/models/Kcp_model.php:8-13` (raw JSON log only), `source-refs/sanmopia_web/application/models/Payment_model.php:166-215` and `:353-380` (waiting status and raw `PAYMENT_CONTEXT` storage), `source-refs/sanmopia_web/application/models/Payment_model.php:512-734` (deposit row lookup, already-paid shortcut, reservation status movement, paid timestamp, notices).
Virtual-account reminders and expiry	`VirtualAccountExpiryScheduler`, `VirtualAccountExpiryTransitionCommand`, `ExpiredVirtualAccountDepositRaceDecision`, `ReservationStateTransitionAudit`, and `PaymentCommunicationWorkflow`	`Missing scheduler proof / Partial foundation`. Existing foundation names typed expiry events, but cron replacement, scheduled lifecycle job persistence, reminder idempotency, frozen instruction amount/deadline reuse, and expiry/deposit race decision are still missing. PHP cron reads provider JSON deadline/bank/account/price and mutates reservation status directly; UI/PHP must not rebuild reminder content or expiry state from `PAYMENT_CONTEXT`.	`source-refs/sanmopia_web/application/controllers/cli/Reservation.php:562-600` (deadline cron calls direct reservation mutation), `source-refs/sanmopia_web/application/models/Reservation_model.php:2960-2993` (deadline query from `PAYMENT_CONTEXT.va_date`, bank, account, price), `source-refs/sanmopia_web/application/models/Reservation_model.php:2998-3031` (status `14 -> 17` plus source change log), `source-refs/sanmopia_web/application/controllers/cli/Reservation.php:646-735` (cancel notice), and `source-refs/sanmopia_web/application/controllers/cli/Reservation.php:760-827` (two-day reminder from raw bank/account/deadline/price JSON).
Branch/HQ settlement mutation provenance	`SFC-20260709-CUR-103`, `SettlementStatementApprovalCommand`, `SettlementBoardMutationProvenanceImport`, `SettlementTransitionAudit`, `SettlementLineAcknowledgement`, `SettlementStatementDatasetRevision`, and `SettlementStatementManualAdjustmentLineCommand`	`Partial; source mutation import missing`. Finance transition audit and payout refresh provenance exist, but source board/detail/coupon/manual-row mutations still need import/backfill with actor, reason, expected revision, source board id, row ids, selected line set, before/after status, and recalculated total fingerprint. Legacy JS/PHP posts authoritative totals, row ids, flags, memo/message, manual etc names/counts/prices, and actor type; model paths flip board/detail/coupon/manual statuses from mutable rows. UI/PHP must not own settlement totals, row completion, membership/delivery/cancelled-coupon flags, or final branch/HQ settlement state.	`source-refs/sanmopia-admin/static/js/calculate_detail.js:85-165` (selected normal/voucher/coupon ids), `source-refs/sanmopia-admin/static/js/calculate_detail.js:184-249` (delivery, coupon fee, flags, `ftotal-price`, `fresult-price`, actor type), `source-refs/sanmopia-admin/static/js/calculate_detail.js:930-1047` and `:1053-1144` (browser recomputes delivery, membership, etc, coupon fee, result totals), `source-refs/sanmopia-admin/application/controllers/Calculate.php:150-312` (controller accepts posted totals/ids/flags/memo and branches by login type), `source-refs/sanmopia-admin/application/models/Payment_model.php:2525-2562`, `:2861-2915`, `:2977-3051`, and `:4265-4308` (board/detail/coupon/etc status mutations), `source-refs/sanmopia-admin/application/models/Payment_model.php:4312-4400` (current board/detail read and completion count), and `source-refs/sanmopia-admin/application/controllers/Calculate.php:568-578` (export by raw board id).
Branch/HQ component readiness and arrears replay	`SFC-20260709-CUR-103`, `SFC-20260708-CUR-088`, `SettlementLineAcknowledgement`, `SettlementComponentReadinessProjection`, `HeadquartersSettlementCloseoutReadinessProjection`, `SettlementComponentReadinessInvalidationAfterPaymentRepair`, and `SettlementBoardRepairReadinessRefresh`	`Partial; backend settlement ledger work may cover line facts, but legacy compatibility still needs imported component readiness plus post-refund/repair invalidation`. Source branch users acknowledge membership fee, delivery, detail rows, coupon rows, cancelled-coupon gift fee, and manual `etc` rows separately; HQ/admin can move board status from request/arrears to complete only after mutable board/detail/coupon/etc flags count as complete. Legacy refund flips local payment rows to refunded status without touching board component flags, so refund or closeout repair after branch acknowledgement can leave stale HQ readiness unless backend refreshes/revokes the component projection. Modern closeout must consume backend-produced ledger facts, imported source board component acknowledgements, settlement statement revision, payment fact revision, and reversal/repair invalidation outcome before final HQ closeout.	`source-refs/sanmopia-admin/application/controllers/Calculate.php:206-211` (HQ zeroes cancelled-coupon fee when not requested), `source-refs/sanmopia-admin/application/controllers/Calculate.php:219-277` (HQ create/confirm/arrears status path), `source-refs/sanmopia-admin/application/controllers/Calculate.php:279-309` (branch component acknowledgement path), `source-refs/sanmopia-admin/application/models/Payment_model.php:2977-3011` (first deposit vs arrears replay), `source-refs/sanmopia-admin/application/models/Payment_model.php:4382-4400` (completion is membership + delivery + detail + coupon flags), `source-refs/sanmopia-admin/application/models/Payment_model.php:4403-4419` (complete-count helper reads mutable detail/coupon/etc rows), and `source-refs/sanmopia_web/application/models/Payment_model.php:423-430` (refund only updates normal/voucher paid row status).
Refund and partial-refund settlement impact	`RecordProviderRefundResultCommand`, `ProviderRefundPaidRowTransition`, `PartialPaymentRefund`, `PaymentRefundIntent`, `ProviderPartialRefundCapabilitySnapshot`, `SettlementRefundImpactProjection`, `SettlementLedgerReversalLine`, and `SettlementStatementInvalidationAfterRefund`	Partial; provider/refund transition, provider-result reporting invalidation queue request, branch settlement export refresh handler, branch/HQ settlement statement and operator-board read-model refresh validation, sales-dashboard snapshot coverage validation, settlement reversal-line persistence, ledger-backed internal runtime entrypoint, workspace-domain artifact grant revocation, internal repair planning, repair execution-attempt persistence, and repair execution-to-ledger-result recording now exist; provider worker/webhook proof, artifact revocation persistence/reissue projection, full sales-dashboard fact recompute, and retry/result-history hardening remain. Legacy full refund calls KCP and then only flips normal/voucher payment rows to refunded status; it does not append settlement reversal lines, invalidate branch/HQ board component readiness, or revoke/reissue already-built settlement exports. Provider payment output exposes `partcanc_yn`, but partial-cancel request fields were not found, only the full-cancel `STSC` command. Backend `9cc034c` now persists provider result plus paid-row transition decision/rejection as a durable Supabase fact before any read model can treat refund state as final. Backend `e038c7c` then persists provider-refund reporting invalidation instructions for sales dashboards, branch/HQ settlement statements, settlement export artifacts, and branch/HQ operator boards with explicit recalculation versus repair flags. Backend `8db9942` wires those instructions into the configured provider-result recording path instead of requiring callers to remember a second handler call. Backend `fa13ef7` adds a typed projection-refresh request plan, dedicated `sanmopia_provider_refund_reporting_refresh` queue workload, and `refresh_requested` invalidation status. Backend `c46382b` consumes the queue payload through a target-refresh handler port and records `refreshed` or `refresh_failed`; backend `6bd851c` implements the `settlement_export_artifact` target by resolving payment id to branch profile, loading the branch settlement dashboard, rebuilding frozen branch reconciliation CSV/XLSX/JSON exports, and running the existing durable export workflow. Backend `e705d7c` hashes the raw invalidation key and normalizes branch profile id before generating workflow/export codes, keeping provider evidence out of report artifact identities. Backend `d478bdb` adds `ProviderRefundSettlementReportingRefreshDispatcher` and `ProviderRefundSettlementReadModelRefreshHandler`, so branch/HQ settlement statement and operator-board invalidations resolve payment id to branch profile, reload the backend settlement dashboard reader, require statement projection evidence for statement targets, and keep unsupported targets explicit. Backend `4bd75d6` adds `ProviderRefundSalesRevenueDashboardRefreshHandler` plus `SupabaseSalesRevenueDashboardRefundImpactSnapshotReader`, so `sales_revenue_dashboard` refresh messages now resolve payment id to branch/reservation and require an existing branch `sales_overview` snapshot containing that reservation before the invalidation can be marked refreshed. Backend `ef0dade` adds `SettlementLedgerReversalLine`, `SettlementRefundImpactPolicy`, `RecordSettlementLedgerReversalLinesAfterProviderRefundCommand`, `ProviderRefundSettlementLedgerReversalRequest`, Supabase persistence for `sanmopia_settlement_ledger_reversal_lines`, and a boundary-safe settlement-continuation bridge that Tach validates without importing payment domain types into settlement. Backend `ebf785d` wires app composition and internal HTTP boundary so one provider-result command records transition decision, queues reporting refresh, and emits settlement reversal lines through Supabase-backed stores. Backend `6120324` adds ledger-backed provider-result recording: the worker route accepts payment id, refund intent, provider result id/reference/status/idempotency, then backend reads `PaymentRefundLedger` for the refund amount and rebuilds the current paid-row snapshot from `sanmopia_provider_refund_paid_row_transition_decisions`. Backend `3e6d83f` adds repair-time artifact grant revocation fields to `SettlementArtifactGrant`, stores revoked grant ids and replacement artifact request code on `SettlementRepairRequest`, and proves contract round-trip. Current internal repair routes persist repair case, permission, gateway-command payload, updated refund ledger, settlement invalidation key, idempotency-keyed execution attempts from the configured billing gateway, and ledger-backed provider-result recording from accepted/rejected repair execution. Modern refund completion must still persist refund reason, original provider attempt/payment fact revision, provider partial-refund capability snapshot, settlement statement revision, full sales-dashboard fact recompute, Kill Bill/provider worker proof, Supabase/stage grant-revocation persistence, and operator-visible reissue lineage before branch/HQ statements or archive exports can be considered final. Provider-success/local-write-failure still needs retry/result-history proof, stage webhook proof, and operator projection beyond execution-to-ledger-result recording.	`source-refs/sanmopia_web/application/models/Payment_model.php:383-440` (full reservation refund scans provider-context rows without a paid-status predicate, calls provider, writes status `2`), `source-refs/sanmopia_web/application/libraries/Kcppayment.php:39`, `:252`, and `:392` (provider partial-cancel capability evidence), `source-refs/sanmopia_web/application/libraries/Kcppayment.php:447-458` (KCP full cancel command), `source-refs/sanmopia-admin/application/libraries/Kcppayment.php:31-42` (admin full cancel command), `source-refs/sanmopia-admin/application/controllers/Calculate.php:248-263` (HQ settles or marks arrears from mutable board flags), `source-refs/sanmopia-admin/application/models/Payment_model.php:2384-2475` (branch/HQ board totals recomputed from mutable payment/coupon/etc rows), `source-refs/sanmopia-admin/application/models/Payment_model.php:2977-3011` and `:4382-4400` (board/component status determines complete vs arrears), and `source-refs/sanmopia-admin/application/controllers/Calculate.php:568-578` (export streams by raw board id and would need invalidation after refund).
Custom discount, surcharge, and settlement adjustment catalog	`SFC-20260708-CUR-088`, `SettlementAdjustmentLineCommand`, `SettlementAdjustmentCatalogRevision`, `SettlementManualDiscountSurchargePolicy`, and `RegionalBenefitSettlementImpactSnapshot`	`Partial; HTTP manual-adjustment contract rejects posted totals, but persisted catalog issuance and source discount parity are incomplete`. Legacy lets operators create positive or negative “other service” rows, post names/counts/prices from the browser, and fold those rows into branch/HQ totals. It also applies branch/region-specific voucher discount arithmetic inside settlement data loading. Modern policy must freeze adjustment effect, reason, quantity, actor scope, catalog revision, regional-benefit revision, and settlement statement revision before recognition.	`source-refs/sanmopia-admin/application/views/modal/modal_other_service_add.php:23-29` (negative price reduces branch remittance), `source-refs/sanmopia-admin/static/js/calculate/other_service_management.js:43-96` (browser add/remove catalog rows), `source-refs/sanmopia-admin/application/controllers/Calculate.php:184-203` and `source-refs/sanmopia-admin/application/controllers/Calculate.php:240-245` (posted `etc` arrays saved with board log), `source-refs/sanmopia-admin/application/models/Payment_model.php:2861-2908` (manual rows persisted), `source-refs/sanmopia-admin/application/models/Payment_model.php:962-964` and `source-refs/sanmopia-admin/application/models/Payment_model.php:2442-2475` (manual rows folded into totals), and `source-refs/sanmopia-admin/application/models/Payment_model.php:3759-3767` (hardcoded Yeongdeungpo discount in voucher settlement calculation).
Settlement document/export UX and archive grants	`SFC-20260708-CUR-088`, `SFC-20260708-CUR-098`, `SFC-20260709-CUR-103`, `SettlementArchiveRequest`, `SettlementStatementDatasetRevision`, `SettlementArtifactGrant`, and `SettlementArtifactBuildRunLedger`	`Partial; export-line/dataset foundations exist, but data-room handoff and grants remain missing`. Legacy data-room tables navigate by raw `dataType` and board id, export endpoints accept `excelType`/`boardId`, spreadsheet builders reload mutable rows, recompute fees/net deposits, insert formulas, and stream the workbook directly. Modern UX needs actor-bound artifact requests, frozen dataset revisions, signed grants, build ledger rows, and no route or spreadsheet formula authority from board ids.	`source-refs/sanmopia-admin/static/js/data_room/calculate_central.js:10-14` and `source-refs/sanmopia-admin/static/js/data_room/calculate_danvi.js:10-14` (raw board/detail navigation), `source-refs/sanmopia-admin/application/views/table/data_room/table_calculate_central.php:43-60` and `source-refs/sanmopia-admin/application/views/table/data_room/table_calculate_danvi.php:29-49` (table buttons expose board ids and data type), `source-refs/sanmopia-admin/application/controllers/Calculate.php:568-578` (raw export request), `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3741-3772` (reloads board/detail rows), `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3795-3880` (writes mutable service/coupon net deposit rows), and `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3898-3911` (spreadsheet formula plus direct output stream).

2026-07-09 persistent legacy-mining status refresh

No new feature ids are added here; the rows below attach additional source evidence and backend-owned rules to already-listed checklist owners so the checklist does not duplicate SFC entries.

CaregiverMatchingProfileRevision and matching-candidate input facts. Existing owner rows: caregiver matching preference/profile checklist row, SFC-20260708-CUR-084, and SFC-20260708-CUR-089. Status: Partial. Backend foundation exists for caregiver profiles and assignment analysis, but legacy manager self-service profile writes are not yet proven as imported, versioned, optimizer-visible profile revisions. Evidence: source-refs/sanmopia-manager/application/controllers/Matching.php:43-65 posts pet allergy/type/size/count/isolation, religion, ranked service preference, and personality values; source-refs/sanmopia-manager/application/models/Matching_model.php:140-186 inserts or updates MANAGER_MATCHING_INFO_TB; source-refs/sanmopia-manager/application/models/Matching_model.php:188-260 rewrites ranked service preference rows by fixed sequence; and source-refs/sanmopia-manager/application/models/Matching_model.php:263-304 deletes and reinserts personality-by-manager rows. Backend rule: these mutable manager tables are source evidence only. Modern matching must persist versioned profile revisions, catalog references, approval/source surface, and optimizer invalidation before any reservation assignment, payout, or branch coverage projection uses the data.
ServiceSuspensionRequest / holiday-or-service-pause financial invalidation. Existing owner rows: service suspension workflow rows plus SFC-20260708-CUR-065 and SFC-20260708-CUR-067. Status: Partial. Backend-side status and projection foundations exist, but the customer web-originated stop/pause request, branch notification, and downstream refund/settlement/payout invalidation are not yet E2E-proven. Evidence: source-refs/sanmopia_web/static/js/mypage/reservation.js:326-365 posts a cancel/stop/change request with reservation id and freeform reason; source-refs/sanmopia_web/application/controllers/api/Reservation.php:86-139 validates the logged-in customer and dispatches the stop command branch; source-refs/sanmopia_web/application/models/Reservation_model.php:1091-1111 flips reservation status to RESERVATION_STATUS_STOP_REQ and writes RESERVATION_REQUEST_TB; and source-refs/sanmopia_web/application/controllers/api/Reservation.php:192-208 sends branch notifications, including a special secondary recipient branch path. Backend rule: pause/stop is not a UI status flip. It must be a command with actor proof, expected reservation revision, notification dispatch audit, and explicit recalculation/invalidation facts for refund, coupon, service occurrence, caregiver payout, branch settlement, and archive views.
ServiceAreaCoverageDecision and branch coverage profile import. Existing owner rows: branch service-area decision snapshot, coverage profile, and branch coverage override checklist rows. Status: Partial. Backend coverage concepts exist, but the legacy possible/consultation/impossible area precedence and special address matching still need import provenance and booking/matching E2E proof. Evidence: source-refs/sanmopia_web/application/models/Branch_model.php:38-89 matches branch area by address levels and area type; source-refs/sanmopia_web/application/models/Branch_model.php:93-140 applies impossible-area veto checks before returning a branch; and source-refs/sanmopia-admin/application/models/Branch_model.php:337-425 writes possible, consultation, and impossible service-area rows while requiring consultation/impossible areas to be nested under an existing possible area. Backend rule: modern booking and matching must consume a versioned ServiceAreaCoverageDecision projection, not live branch tables or UI-side address heuristics; unavailable/impossible veto must outrank consultation and available coverage in backend policy.
SettlementArchiveRequest and branch/head-office approval provenance. Existing owner rows: SFC-20260709-CUR-103, SFC-20260708-CUR-088, and SFC-20260708-CUR-098. Status: Partial. Branch/HQ settlement board and approval vocabulary are represented, but archive/export UX still needs frozen-dataset grants, actor-bound artifact requests, and imported mutation provenance for legacy settlement actions. Evidence: source-refs/sanmopia-admin/application/controllers/Calculate.php:150-312 accepts posted reservation/coupon ids, totals, branch flags, membership/cancel coupon fields, and actor type for branch-to-head-office settlement actions; source-refs/sanmopia-admin/application/controllers/Calculate.php:315 routes the settlement data room; and source-refs/sanmopia-admin/application/controllers/Calculate.php:568-578 exports spreadsheets from raw board id and excel type inputs. Backend rule: export/download and approval screens must be read-only artifact projections over frozen settlement statements. Posted totals, board ids, excel type, and legacy login type are migration evidence only; modern actions require SpiceDB-backed actor grants, expected statement revision, immutable action journal, and export artifact audit.
Provider-success/local-write-failure refund repair and partial refund proof. Existing owner rows: virtual-account/payment lifecycle and provider compensation rows from the 2026-07-09 checklist refresh. Status: Partial after runtime KillBill paid-webhook workflow-start failure now persists a provider attempt and compensation intent, and /internal/payment-refund-repairs/provider-refund-plans now persists the repair plan. Backend also exposes /internal/payment-refund-repairs/provider-refund-executions, calls the configured Kill Bill gateway through PaymentGatewayClient.refund, and persists execution attempts in sanmopia_payment_refund_repair_execution_attempts, then records accepted or rejected repair execution results through ProviderRefundResultFromLedgerHandler. Still Missing for retry/result history hardening, live Kill Bill-originated callback proof, same-id conflict quarantine, and operator repair projection. Synthetic ExtBusEvent stage callback/queue/ledger wiring now passes. Backend rule remains unchanged: provider success paired with local write failure must persist a provider attempt, compensation intent, refund repair plan, execution attempts, retry/result history, and operator-visible projection before settlement can treat the reservation as financially closed. UI/PHP refund buttons, provider callbacks, Korean status strings, and manual amount fields are evidence only; backend owns refund, partial refund, custom charge, discount, and settlement impact calculation.

No new SFC ids. These refine existing branch-operations and business-reporting owner rows without entering the settlement data-room lane.

BranchProfileRevision and settlement-facing branch facts. Existing owner rows: branch_operations / office_profile, operator_access / branch_login_audit, BranchCoverageDecision, SettlementRemittanceAccountSnapshot, and BranchMembershipDueAcknowledgementPolicy. Status: Partial. Evidence: source-refs/sanmopia-admin/application/controllers/OfficeManagement.php:407-432 posts branch identity, membership fee, office status, password, and primary / secondary remittance accounts from one admin form; source-refs/sanmopia-admin/application/models/Branch_model.php:207-242 writes the mutable branch profile, account, password, and status fields; source-refs/sanmopia-admin/application/models/Branch_model.php:261-285 computes the current membership month key from server date and overwrites the branch membership fee row; source-refs/sanmopia-admin/application/models/Branch_model.php:345-426 maps possible/consult/impossible area strings and rejects subordinate coverage rows when no possible area exists; and source-refs/sanmopia-admin/application/models/Branch_model.php:435-517 plus source-refs/sanmopia-admin/application/models/Branch_model.php:526-606 overwrite or delete branch profile/stamp files and service-area rows. Backend rule: branch_operations owns revisioned branch profile, service-area, and brand-asset commands; operator_access owns credential rotation; pricing_settlement owns membership-fee schedules and remittance account snapshots; document_reporting consumes branch brand-asset snapshots. UI/PHP must not calculate membership period keys, decide coverage hierarchy, rotate credentials, or mutate settlement-facing remittance/brand facts without expected revision, reason, and audit.
AdminRevenueStatisticsProjection and mutable paid-row report formulas. Existing owner row: business_reporting / admin_analytics_catalog. Status: Partial. Evidence: source-refs/sanmopia-admin/application/controllers/Statistics.php:433-453 issues separate total/government-fee/coupon/offline metric requests; source-refs/sanmopia-admin/application/models/Statistics_model.php:1070-1182 groups sales by deposited date and computes total, offline, government, fee, and coupon amounts with hardcoded service-type/status branches; source-refs/sanmopia-admin/application/models/Statistics_model.php:1812-1856 joins mutable paid rows, coupon rows, and fee SQL functions to calculate revenue; source-refs/sanmopia-admin/application/models/Statistics_model.php:1860-1948 builds branch/product/work-style counts and sums using string comparisons, status filters, and branch exclusions; and source-refs/sanmopia-admin/static/js/statistics/sales.js:630-685 plus source-refs/sanmopia-admin/static/js/statistics/sales.js:1153-1168 request chart/table datasets and combine totals client-side. Backend rule: business_reporting needs versioned metric definitions and projection refresh jobs keyed by payment/refund/closeout/settlement invalidation. pricing_settlement supplies immutable paid-row, fee, coupon, and refund facts. UI/PHP must not infer sales eligibility, additional/offline buckets, product/work-style buckets, fee totals, or branch exclusions from mutable reservation/payment rows.

No new SFC ids. These refine existing settlement/data-room owners only: SFC-20260708-CUR-088, SFC-20260708-CUR-098, SFC-20260709-CUR-103, settlement data-room worklist rows, and data-room mailbox rows.

SettlementDataRoomWorklistSnapshot, ReservationDocumentBundleSelectionGrant, and SettlementDataRoomFilterStateToken. Status: Partial. Evidence: source-refs/sanmopia-admin/application/controllers/DataRoom.php:30-83 accepts GET branch/date filters into the form-list page; source-refs/sanmopia-admin/application/controllers/ajax/DataRoom.php:17-64 accepts branch/date/form/table parameters; source-refs/sanmopia-admin/application/controllers/ajax/DataRoom.php:91-130 chooses eligible statuses and service/document filters; source-refs/sanmopia-admin/application/controllers/ajax/DataRoom.php:132-240 performs search, sort, and paging in PHP memory; and source-refs/sanmopia-admin/static/js/data_room/form_reservation_list.js:1-47 preserves branch filter in URL hash and posts raw filters to AJAX. Backend rule: data-room worklists need persisted filter snapshot, actor scope, SQL-backed page cursor, selected reservation tokens, and return-state token. Hash state, raw branch ids, DataTables order columns, and PHP-memory result slicing are migration evidence only.
AllDocumentBundlePolicy and ReservationDocumentSelectionConflictDecision. Status: Partial. Evidence: source-refs/sanmopia-admin/static/js/data_room/form_reservation_list.js:62-87 treats integrated document form 16 as single-select only in browser code and posts hidden reservation[service_type]; source-refs/sanmopia-admin/static/js/data_room/form_reservation_list.js:219-246 submits selected reservations through a hidden iframe; and source-refs/sanmopia-admin/application/controllers/DataRoom.php:311-386 trusts posted reservation ids/service type, chooses voucher vs normal bundle from the first selected reservation, then calls spreadsheet rendering. Backend rule: bundle policy must enforce single-vs-multi selection, homogeneous service type, document eligibility, expected worklist revision, and artifact request id. UI-hidden service-type values and iframe posts cannot choose printable document sets.
BranchDocumentMailboxPostRevision and DocumentAttachmentVersionGrant. Status: Mapped/Partial. Evidence: source-refs/sanmopia-admin/application/controllers/DataRoom.php:97-197 routes other-post view/list/write/submit/delete from board type, branch ids, uploaded attachment names, and posted delete-file ids; source-refs/sanmopia-admin/application/models/Data_room_model.php:25-80 applies branch-36/headquarters/null-branch send/receive visibility rules; source-refs/sanmopia-admin/application/models/Data_room_model.php:105-184 updates or inserts posts, uploads files, deletes selected file rows, then deletes physical files; and source-refs/sanmopia-admin/application/models/Data_room_model.php:189-202 deletes a post and physical upload directory by post id. Backend rule: mailbox actions need post revision, participant branch snapshots, attachment version ids, delete/revoke grants, actor permission, and immutable audit. Posted branch ids, fixed-post flags, mutable file URLs, and physical delete side effects are source evidence only.
SettlementStatementRevisionConflictDecision and SettlementBoardActionJournal. Status: Partial. Evidence: source-refs/sanmopia-admin/application/controllers/Common.php:80-130 rebuilds a branch/HQ settlement detail page from GET year/month/branch and current board status; source-refs/sanmopia-admin/static/js/calculate_detail.js:80-170 collects checked normal/voucher/coupon/reservation ids into posted arrays; source-refs/sanmopia-admin/static/js/calculate_detail.js:930-1144 recomputes delivery, membership, coupon-fee, manual-etc, and result totals in browser state; source-refs/sanmopia-admin/application/controllers/Calculate.php:150-272 accepts posted totals, flags, board id, data type, and manual lines; source-refs/sanmopia-admin/application/controllers/Calculate.php:245-270 and source-refs/sanmopia-admin/application/controllers/Calculate.php:279-309 call insertLog during HQ confirmation/rejection and branch acknowledgement; source-refs/sanmopia-admin/application/models/Payment_model.php:25-31 logs before/after values plus branch id but ignores the passed board id; and source-refs/sanmopia-admin/application/models/Payment_model.php:2977-3031 changes board status from mutable board/component flags without expected statement revision. Backend rule: request, acknowledgement, arrears replay, and completion need expected statement revision, frozen line ids, component-level acknowledgements, actor grant, idempotency key, and conflict decision. SettlementTransitionAudit, SettlementApprovalProvenanceSnapshot, and RefundRepairSettlementImpactJournal must link branch/HQ/Danbee approvals to the exact statement revision and downstream artifact supersession/grant revocation. Browser totals and board-id status switches are not authority.
SettlementArtifactBuildRunLedger and SettlementExportDatasetRevision. Status: Partial. Evidence: source-refs/sanmopia-admin/application/views/table/data_room/table_calculate_central.php:43-60 and source-refs/sanmopia-admin/application/views/table/data_room/table_calculate_danvi.php:29-49 expose board ids and data-type through detail buttons; source-refs/sanmopia-admin/static/js/data_room/calculate_central.js:10-14 and source-refs/sanmopia-admin/static/js/data_room/calculate_danvi.js:10-14 navigate by raw board id; source-refs/sanmopia-admin/application/controllers/Calculate.php:568-578 exports by GET excelType and boardId; and source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3741-3911 reloads mutable board rows, recalculates coupon payment-method fees in the renderer, writes spreadsheet formulas, streams to php://output, and exits. Backend rule: settlement exports need frozen dataset revision, formula policy version, line checksums, render attempt, artifact checksum, signed grant, and revocation/reissue history after refund or board repair. 2026-07-10 grant-linkage refinement: after refund or repair, backend 3e6d83f workspace-domain SettlementWorkspace.request_repair now revokes active SettlementArtifactGrant records for the invalidated artifact version and records revoked_grant_ids plus replacement_artifact_request_code on the repair request. 2026-07-10 Supabase adapter follow-up proves saved workspace JSON rows round-trip grant revocation and repair lineage. Remaining migration must stage-prove that path, then operator-project SettlementArtifactReplacementRequestLink from superseded artifact id to replacement artifact request id. Source export streams directly from mutable board rows and document selections, so it has no durable artifact, grant, or replacement boundary. Evidence: source-refs/sanmopia-admin/application/controllers/Calculate.php:568-578, source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3741-3911, source-refs/sanmopia-admin/application/controllers/DataRoom.php:85-94, and source-refs/sanmopia-admin/application/controllers/DataRoom.php:312-376.
PrintableDocumentArtifactBuildRun and DocumentTemplateVersionManifest. Status: Partial. Evidence: source-refs/sanmopia-admin/application/controllers/DataRoom.php:85-95 exposes raw excelType and reservation-id export; source-refs/sanmopia-admin/application/controllers/DataRoom.php:311-386 posts selected reservation ids into document download; source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3914-4198 renders documents from live reservation/report rows, copies static PDFs into temp paths, writes XLSX temp files, zips them, deletes temp files, and streams output; and source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:4028-4050 chooses daily-report first/middle/last artifacts from current report rows, service end date, and stop-day lookup. Backend rule: document generation needs template manifest version, source projection revision, report finality decision, build-run ledger, artifact retention policy, and signed download grant. Runtime temp files and live read-time document selection are source evidence only.

2026-07-10 Reservation-To-Settlement Source Authority Consolidation

No new SFC ids. These entries consolidate source evidence under existing owner rows instead of duplicating service-calendar, pricing, caregiver, and settlement checklist items. Each item is a backend-authority migration requirement; UI/PHP calculations are evidence only.

Legacy evidence path	Modern ubiquitous name	Target bounded context / feature slice	Backend authority rule	Implementation status	Verification gap
`source-refs/sanmopia_web/static/js/basePrice.js:1-170` and `source-refs/sanmopia_web/static/js/basePrice.js:185-360` hardcode service duration choices, caregiver salary, government support, and mother payable by child/service category in browser JavaScript.	`ServiceOfferingCatalogRevision`, `CaregiverCompensationRateCatalog`, `MotherVisibleChargeCatalogSnapshot`	`pricing_settlement / product_catalog`, `pricing_settlement / caregiver_compensation`, `reservation_operations / quote_projection`	Supabase-backed catalog revisions must own service duration, government support, customer-payable, and caregiver-compensation rate rows. Reservation UI and legacy import adapters may render or cite catalog snapshots, but must not embed wage/support/payable matrices.	`Partial`; product pricing and finalized charge snapshot foundations exist. Backend `7f8ca36` adds `BasePriceCatalogMatrixParser`, converting legacy `basePrice.js` matrix cells into versioned `PriceCatalogEntry` rows with canonical birth-multiplicity, child-order, benefit-type, regional-support, caregiver-compensation, government-support, and mother-visible-charge components. Supabase persistence can reuse the existing price catalog import repository.	Run/import full `basePrice` matrix into versioned catalog tables, quote a reservation from catalog revision only, generate caregiver payout from the same revision, and prove branch/HQ settlement consumes frozen charge and compensation lines rather than JS/PHP arrays.
`source-refs/sanmopia_web/static/js/step3_normal.js:86-110` branches a continuation booking into smart matching or review based on returned flags and routes the browser accordingly; `source-refs/sanmopia_web/static/js/step3_normal.js:127-145` multiplies selected baby-option price by service day before rendering added charges.	`ReservationContinuationHandoffDecision`, `MatchingRequirementDecision`, `AdditionalCareOptionChargeLine`	`reservation_operations / continuation_booking`, `caregiver_assignment / matching_requirement`, `pricing_settlement / reservation_charge_lines`	Backend must return a frozen continuation handoff with matching requirement, copied-fact audit key, caregiver carryover decision, and charge-line snapshot. Browser route choices and option amount math are projection data only.	`Partial`; continuation link and service-calendar facts exist, but all customer/admin continuation paths still need binding to backend handoff and catalog-backed added-charge projection.	E2E continuation proof for same-caregiver available/unavailable, smart-matching-required, added baby-option charge line, and settlement/payout invalidation from the accepted continuation plan.
`source-refs/sanmopia-manager/application/views/schedule/schedule_info.php:136-203` lets the caregiver-facing schedule view decide service-balance command availability, recalculate Saturday/holiday/add-on balances, add normal-service balance, include voucher add price, and divide the result across assistant caregivers.	`CareTeamServiceBalanceShareProjection`, `CareManagerServiceBalanceAcknowledgementProjection`, `SubCaregiverServiceBalanceReceiptSlot`	`pricing_settlement / service_balance_closeout`, `caregiver_compensation / care_team_receipts`, `operator_access / caregiver_account_disclosure`	Backend must compute main/assistant service-balance shares from finalized charge snapshot, occurrence ledger, care-team roster revision, and receipt state. Caregiver UI may request acknowledgement/disclosure commands with grants, but must not recalculate balance shares or command availability.	`Partial`; backend `fbc60e4` reads frozen closeout, receipt-state, and payout-instruction facts into the caregiver work-schedule projection, supports a versioned equal-slot policy for multiple caregivers, and provides reservation-scoped lookup. Stage reservation `0b57b5f1-12c5-42f0-bcdf-7ab90e469a8b` reached `settled` with a frozen 25,000 KRW share. Backend `65a71ac` materializes accepted assignment decisions into `sanmopia_reservation_caregiver_assignments`, including resolved profile/auth identity, grade, occurrence-ledger day count, booking dates, slot identity, and `assigned`/`replaced`/`removed` lifecycle. Stage reservation `5dd549d3-6c2c-407c-b42a-fdcd7e769c6a` persisted the roster before payout and reached `settled`.	Prove decision persistence and projection cannot strand divergent state: add durable retry/repair and idempotent replay for projection failure, then backfill and reconcile older accepted decisions against materialized roster rows before downstream payout/settlement use.
`source-refs/sanmopia_web/static/js/priceList.js:8-43` hardcodes public option prices by service type; `source-refs/sanmopia_web/static/js/menu/feeguide.js:1-83` hardcodes voucher fee year suffixes and image filenames; `source-refs/sanmopia_web/application/views/about/fee_table.php:57-95` embeds one-week public service and Saturday prices directly in markup.	`PublicFeeGuideCatalogProjection`, `PublicServiceFeeQuotePreview`, `PublicFeeGuideArtifactCatalog`	`pricing_settlement / public_fee_guide_catalog`, `pricing_settlement / product_catalog`	Backend must publish effective-dated public fee rows, option prices, voucher artifact mappings, and display-period metadata. Public UI may render a catalog projection, but must not decide price/version/image path from JavaScript constants, static markup, or filename conventions.	`Partial`; public fee guide is listed as a migration owner, but exact legacy hardcoded option-price and image-catalog evidence still needs import/backfill proof.	Seed/import public fee guide catalog rows for normal/special/in-home and voucher image artifacts, expose a read projection for the public guide, and prove customer quote/payment uses the same catalog revision instead of separate browser constants.
`source-refs/sanmopia_web/application/views/service/step3_selecttype.php:58-94` hides or shows pre-reservation and in-home service cards from delivery timing, reservation status, baby count, and price version; `source-refs/sanmopia_web/application/views/service/step3_selecttype.php:107-119` routes continuation bookings around caregiver search; `source-refs/sanmopia_web/application/views/service/step3_selecttype.php:232-236` leaves a price-table-change pre-reservation shutdown alert as commented UI policy; `source-refs/sanmopia_web/static/js/step3_selecttype.js:23-31` sends pre-reservation directly to a payment route with year-boundary warning copy.	`ReservationServiceOfferingAvailabilityDecision`, `ServiceOfferingShutdownWindow`, `PreReservationConversionEligibilityProjection`, `ReservationCreationHandoffProjection`	`reservation_catalog / service_offering_availability`, `reservation_operations / reservation_creation`, `pricing_settlement / price_catalog_version_policy`	Backend must decide service offering availability, pre-reservation-only windows, triplet/quadruplet in-home exclusion, continuation route, and year-boundary voucher ambiguity from versioned catalog/policy facts. UI may render allowed actions and message keys only; view `continue`, raw status ids, and ad-hoc comments are source evidence only.	`Partial`; backend `86b9fe9` adds `ReservationServiceOfferingAvailabilityPolicy`, `ReservationServiceOfferingCandidate`, `ReservationServiceOfferingEvaluationContext`, `ServiceOfferingShutdownWindow`, `ReservationCreationHandoffKind`, and Pydantic contract payloads. Backend `d386524` exposes bearer-protected `POST /reservation-service-offering-availability-decisions`, wires it into `main.py`, and returns backend-owned availability state, handoff kind, unavailable reason codes, message keys, policy revision, and source evidence. Backend `77547ef` adds `POST /reservation-service-offering-availability-decision-sets`, a Supabase-backed catalog reader over care service catalog offerings and policy attachments, and focused tests for catalog-loaded candidates and shutdown windows. Backend `3b32580` carries accepted service-offering decisions into reservation booking HTTP/API/workflow input, rejects unavailable accepted decisions before booking/payment, freezes the decision payload for workflow audit, and adds Tach module edges for the service-offering domain feature. Backend `28d858c` rejects accepted price quotes whose entry code is not bound to the accepted service-offering key and rejects price-quote `service_day_count` when it conflicts with the accepted service-term base day count. Tests now cover birth-lead-time pre-reservation availability, after-birth rejection, voucher direct-service blocking during pre-reservation window, triplet/quadruplet in-home exclusion for catalog version 2+, continuation handoff around caregiver search, year-boundary shutdown message keys, HTTP auth, route response shape, catalog-backed decision-set response shape, command rejection of unavailable offering decisions, workflow payload freezing, quote/offering mismatch rejection, and quote/service-term day-count mismatch rejection.	Make accepted service-offering decision mandatory for booking once Astro consumes backend decision sets, bind add-option/rental selection revisions to the same accepted offering and charge snapshot, and prove Astro reservation card E2E consumes backend decision sets instead of static route/card visibility.
`source-refs/sanmopia_web/application/controllers/Service.php:370-388` chooses normal working type and loads add-option catalog rows from the reservation price version; `source-refs/sanmopia_web/application/models/Reservation_model.php:1814-1838` indexes normal add-option prices by `WORKING_TYPE_LIST_ID_FK`; `source-refs/sanmopia_web/application/views/service/step3_normal.php:521-538` renders one-hour `시간추가` quantity and price from `$addOptionData["시간추가"][$workId]`; `source-refs/sanmopia_web/application/views/service/step3_voucher.php:591-614` hides the added-hour selector for in-home voucher service but renders it for commute voucher service; `source-refs/sanmopia_web/static/js/step3.js:742-764` multiplies added-hour price by selected hour quantity and `getServiceDay()` in browser JavaScript.	`ServiceWorkingTimeProfile`, `AdditionalServiceTimeChargeLine`, `CaregiverWorkingWindowPolicy`	`reservation_catalog / service_working_time_policy`, `pricing_settlement / reservation_charge_lines`, `caregiver_assignment / caregiver_availability`	Backend must own working-time eligibility, added-hour quantity bounds, service-type exclusions, catalog-backed added-hour unit price, service-day multiplier, and downstream quote/payment/payout/settlement impact. UI may render backend-projected selectable quantities and charge lines only; browser `timeInput.data("price") * quantity * getServiceDay()` is source evidence, not authority.	`Partial`; service-calendar and charge-snapshot foundations exist, but added-hour working-time profile parity is not separately proven as catalog-backed backend policy.	Add tests for normal commute/in-home and voucher commute/in-home eligibility, tampered added-hour quantity rejection, added-hour charge equals backend catalog unit price times frozen service-day count, and accepted added-hour line invalidating caregiver payout plus branch/HQ settlement projections from the same frozen charge snapshot.
`source-refs/sanmopia_web/application/controllers/api/Service.php:335-414` accepts voucher add-option ids and quantities from the posted form, mutates Wanju service days by `+5`, counts posted Saturday/holiday arrays into option quantities, then stores browser `reservation[endDate]`; `source-refs/sanmopia_web/application/controllers/api/Service.php:456-524` does the same for normal service and directly inserts posted `add_option_baby`; `source-refs/sanmopia_web/application/models/Reservation_model.php:552-564` and `source-refs/sanmopia_web/application/models/Reservation_model.php:698-710` insert add-option id plus quantity without proving the row belongs to the selected service offering, working type, price version, or allowed quantity set; `source-refs/sanmopia_web/static/js/step3.js:613-640` computes effective service days in the browser, `source-refs/sanmopia_web/static/js/step3.js:480-560` renders Saturday/holiday prices from browser-side counts, `source-refs/sanmopia_web/static/js/step3.js:713-731` multiplies child-option price by selected quantity and effective service days, and `source-refs/sanmopia_web/static/js/step3.js:767-832` totals those DOM rows before payment review; `source-refs/sanmopia_web/application/controllers/api/Service.php:705-759` later chooses consultation/payment handoff and writes voucher live-in/special service-balance left price from the mutable current price table; `source-refs/sanmopia-admin/application/models/Reservation_model.php:194-229` reattaches mutable add-option rows and derived `PRICE_TABLE` for admin/export use; `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:417-465` and `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:728-748` render add-option charge rows into service-use/downpayment document artifacts from `PRICE_TABLE` strings and current option labels.	`ReservationAddOptionSelectionRevision`, `ReservationSubmissionIntegrityGuard`, `ReservationPaymentSettlementHandoffSnapshot`, `CaregiverPayoutChargeImpactSnapshot`, `ReservationChargeDocumentSnapshot`	`reservation_operations / reservation_submission`, `pricing_settlement / reservation_charge_lines`, `caregiver_compensation / payout_projection`, `branch_settlement / settlement_seed_projection`, `document_reporting / reservation_charge_artifact_projection`	Backend must validate every submitted add-option id against selected offering, working-type profile, price catalog revision, regional-benefit decision, and allowed quantity policy; recompute selected-day counts and end date from occurrence facts; freeze canonical charge lines before payment handoff; and publish the same charge-snapshot references to caregiver payout, branch/HQ settlement seeds, and document artifact build inputs. UI/PHP/renderers may submit user intents or render backend projections only, never authoritative option ids, service-day multipliers, end dates, settlement-bearing service-balance amounts, parsed display strings, or mutable option labels.	`Partial`; service-calendar plans, finalized charge snapshots, service-balance closeout references, and added-hour policy gaps are mapped. Backend `ed16356` now rejects booking service-term side effects unless the command carries accepted price quote, accepted service-offering availability decision, and accepted service-term plan, so add-option/service-term side effects cannot enter booking from standalone UI payloads. Backend `836d3ba` now rejects add-option charge links whose charge component code is absent from the accepted quote lines. Backend `06adfba` now rejects selected add-option keys or add-option charge-link selection keys that are absent from the accepted backend service-term plan. Backend `6685429` now rejects side-effect assemblies that omit chargeable additional service days selected by the accepted backend service-term plan. Backend `1447053` now rejects missing, unselected, or duplicate add-option charge links at command construction before payment approval. Legacy add-option id/quantity submission integrity and direct handoff from accepted selection revision to payout/settlement/document projections still need proof.	Add tests that reject voucher/normal add-option ids from the wrong service type, working type, price version, or branch catalog; reject tampered child/hour quantities and client end date; prove Wanju, Saturday, and holiday counts are recomputed from backend occurrence and regional-benefit facts; assert payment handoff uses the accepted charge snapshot id; and assert caregiver payout, branch/HQ settlement seeds, and printable document artifacts reference the same finalized charge/selection revision after add-option acceptance or repair.
`source-refs/sanmopia_web/application/views/service/step3_normal.php:188-242` and `source-refs/sanmopia_web/application/views/service/step3_voucher.php:260-314` render rental goods with posted `rental[]` ids, browser `data-price`, a hardcoded 10,000 KRW round-trip delivery notice, and a breast-pump availability warning that depends on branch circumstances; `source-refs/sanmopia_web/static/js/step3.js:92-155` and `source-refs/sanmopia_web/static/js/step3.js:158-195` add rental item rows and a one-time delivery fee from browser DOM state; `source-refs/sanmopia_web/application/controllers/api/Service.php:416-419` and `source-refs/sanmopia_web/application/controllers/api/Service.php:531-534` delete and reinsert posted rental ids for voucher/normal booking submissions; `source-refs/sanmopia_web/application/models/Reservation_model.php:796-803` inserts those rental ids without catalog/branch/availability proof; `source-refs/sanmopia_web/application/models/Reservation_model.php:1231-1259` sums selected rental rows plus `DELIVERY_FEE`, and `source-refs/sanmopia_web/application/models/Reservation_model.php:1318-1348` feeds rental price into voucher service-balance or normal left-price/payment totals; `source-refs/sanmopia-admin/application/models/Reservation_model.php:216-229` reattaches current rental rows before deriving `PRICE_TABLE`; `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:663-709` hardcodes rental item names, breast-pump price, and 10,000 KRW delivery into downpayment artifacts; `source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3950-3952` loads all rental catalog rows for document rendering.	`ReservationRentalSelectionRevision`, `RentalEquipmentAvailabilityDecision`, `RentalDeliveryChargeLine`, `RentalSettlementImpactSnapshot`, `RentalDocumentChargeSnapshot`	`reservation_catalog / rental_equipment_catalog`, `reservation_operations / reservation_submission`, `pricing_settlement / reservation_charge_lines`, `branch_settlement / settlement_seed_projection`, `document_reporting / reservation_charge_artifact_projection`	Backend must validate rental selection ids against effective catalog, branch availability, delivery-fee max-once policy, price revision, and accepted service offering; freeze rental item and delivery charge lines before payment handoff; and publish rental charge references to service-balance closeout, branch/HQ settlement seeds, and document artifact build inputs. UI/PHP/renderers may render selectable rental projections and warnings, but must not decide rental availability, delivery-fee amount, document rental checkmarks, hardcoded rental item prices, or settlement-bearing rental totals from DOM fields or Korean item names.	`Partial`; immutable rental catalog publication/read boundary and actual HQ administration are complete. Backend `4c9dd40f` plus frontend `3dd5779` prove real GoTrue HQ/unauthorized actors, accepted SpiceDB authority, production Supabase/FastAPI/Astro composition, UI publication `5 → 6`, exact replay, altered replay rejection with unchanged DB, unauthorized GET/POST `403`, append-only revision/supersession/evidence lineage, desktop table/mobile card replacement, and full cleanup without route interception. Backend `7f51408b` adds the explicit immutable rental-selection cross-context contract and binds effective catalog facts, accepted offering, branch confirmation, max-once delivery, quote/payable, charge-handoff revisions, accepted booking command, Restate input, and finalized charge policy version. Backend `288e14a7` plus frontend `93b8c2e1` prove an authenticated mother selecting `health_cushion_rental` through the actual desktop/mobile chat, Supabase draft/materialization, voucher quote with KRW `0` equipment and KRW `10,000` max-once delivery, KRW `210,000` payable, immutable rental catalog/selection handoff hashes, final review `200`, edit/reprojection, and actual `422/409/403/401`. Unknown/out-of-catalog, duplicate, branch-unconfirmed, offering/amount/pricing-lineage drift, and public contract leakage fail closed. Full Python is `7,087 passed`; frontend is `95 files / 592 tests`; Tach diagnostics are `0`.	Exercise confirmation-ready legal acceptance and actual Supabase booking/payment workflow; publish the frozen selection revision to service-balance closeout, caregiver payout display where applicable, branch/HQ settlement seeds, and printable document artifacts; prove every consumer rejects mutable current-catalog drift and references the same frozen selection revision.
`source-refs/sanmopia_web/application/views/service/reservation_check_data.php:304-334` renders coupon ids as hidden booking-review fields; `source-refs/sanmopia_web/application/controllers/api/Service.php:735-739` deletes and reinserts posted normal-reservation coupon rows before payment handoff; `source-refs/sanmopia_web/application/controllers/Service.php:721-750` mutates pre-reservation service type and coupon rows during the payment-page GET; `source-refs/sanmopia_web/application/views/service/pre_reservation_payment.php:123-143` subtracts coupon prices from the pre-reservation provider amount in PHP view state; `source-refs/sanmopia_web/application/models/Reservation_model.php:1990-2008` deletes coupon selections by nullable `PRERESERVATION_FL`; `source-refs/sanmopia_web/application/models/Reservation_model.php:2013-2033` inserts coupon selection rows after a current wallet lookup; `source-refs/sanmopia_web/application/models/Payment_model.php:140-152` flips user-coupon `USE_FL` during paid reservation closeout; `source-refs/sanmopia_web/application/models/Payment_model.php:775-843` creates pre-reservation payment rows, virtual-account waiting status, and over-credit point/shop grants from current price-table coupon values; `source-refs/sanmopia_web/application/models/Coupon_model.php:530-553` and `source-refs/sanmopia-admin/application/models/Coupon_model.php:935-958` reopen used coupons on customer/admin cancellation by mutating `USE_FL` and appending a free-text reuse log; `source-refs/sanmopia-admin/application/models/Reservation_model.php:184-229` and `source-refs/sanmopia-admin/application/models/Reservation_model.php:731-790` reattach used coupon rows and recalculate user-fee/left-price document inputs from mutable coupon state; `source-refs/sanmopia-admin/application/models/Reservation_model.php:871-916` feeds coupon-adjusted `PRICE_TABLE` values into service-balance and document projections.	`ReservationCouponSelectionRevision`, `CouponUseLedgerEntry`, `PreReservationCouponCreditCloseout`, `CouponSettlementImpactSnapshot`, `CouponDocumentChargeSnapshot`	`promotion_entitlement / coupon_use_authority`, `pricing_settlement / reservation_charge_lines`, `payment_processing / payment_closeout`, `branch_settlement / settlement_seed_projection`, `document_reporting / reservation_charge_artifact_projection`	Backend must separate coupon selection intent, payment-closeout consumption, pre-reservation credit/over-credit fulfillment, cancellation/refund restoration, settlement impact, and document charge impact into immutable ledger facts with actor, reason, source payment revision, charge snapshot revision, and idempotency. UI/PHP/renderers may render selectable coupon projections and submit coupon-intent tokens only; GET payment pages, hidden coupon ids, nullable pre-reservation flags, user-coupon mutable flags, and read-time `PRICE_TABLE` recomputation must not be booking, payment, refund, settlement, or document authority.	`Partial`; `PreReservationCouponOverCreditPolicy`, product-coupon reset, refund side-effect planning, and frozen charge snapshots exist, but coupon selection revision, closeout-use ledger, cancellation/refund restoration ledger, settlement projection invalidation, and document artifact invalidation still need end-to-end persistence proof.	Add tests that reject hidden coupon ids for another user, already-used/deleted/expired coupons, and stale pre-reservation coupon flags; prove pre-reservation payment page does not mutate coupon authority on GET; prove zero-payable and virtual-account pre-reservation closeout emit coupon-use and over-credit facts after payment persistence; prove cancellation/refund restores coupon availability through a ledger event; prove branch/HQ settlement, caregiver payout, and printable document projections consume coupon impact from the same frozen charge/payment revision.

Downstream consumer refinement for the three selection-revision rows above:

ReservationAddOptionSelectionRevision must become the ubiquitous source name for selected additional service time, child/family add-on, Wanju, Saturday, holiday, and other extra-day charge rows. Payment handoff evidence: source-refs/sanmopia_web/application/models/Payment_model.php:50-68 writes normal/voucher payment rows by service type, and source-refs/sanmopia_web/application/models/Payment_model.php:157-226 copies PRICE_TABLE["userFeeSecurityPrice"], userFeeBalancePrice, and leftPrice into PAYMENT_USER_RESERVATION_*_TB; those prices already include add-option and extra-day totals from source-refs/sanmopia_web/application/models/Reservation_model.php:1231-1369. Caregiver payout evidence: source-refs/sanmopia-admin/application/models/Reservation_model.php:3235-3264 reloads rental and add-option rows for a reservation, and source-refs/sanmopia-manager/application/helpers/salary_helper.php:102-145 recomputes Saturday/holiday/service-day multipliers into caregiver added-service pay before source-refs/sanmopia-manager/application/views/pay_info_detail.php:201-249 renders final salary. Branch/HQ settlement evidence: source-refs/sanmopia-admin/application/models/Payment_model.php:198-278 summarizes payment rows for HQ-to-branch settlement, and source-refs/sanmopia-admin/application/models/Payment_model.php:4155-4222 separately rebuilds service-balance price by joining RESERVATION_ADD_OPTION_VOUCHER_TB and RESERVATION_ADD_OPTION_NORMAL_TB. Danbee settlement evidence: source-refs/sanmopia-admin/application/models/Payment_model.php:3190-3232 reads payment rows into Danbee settlement worklists, and source-refs/sanmopia-admin/application/models/Payment_model.php:384-523 adds their amounts and fee rows. Printable document evidence: source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:340-373, source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:417-465, source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:645-714, and source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:728-748 render add-option and extra-day amounts into fee-agreement, service-use, and downpayment artifacts. Refund/repair evidence: source-refs/sanmopia_web/application/models/Reservation_model.php:990-1035 triggers refund plus coupon restore during instant cancellation, and source-refs/sanmopia_web/application/models/Payment_model.php:383-430 refunds provider payment rows then marks normal/voucher payment rows refunded. Remaining backend gap: persist one ReservationAddOptionSelectionRevision consumer contract through ReservationPaymentSettlementHandoffSnapshot, CaregiverPayoutChargeImpactSnapshot, BranchSettlementSeedProjection, HeadquartersSettlementSeedProjection, ReservationChargeDocumentSnapshot, and RefundRepairProjectionInvalidation; all consumers must reference the same persisted revision key, finalized charge snapshot id, payment fact revision, and repair/reissue lineage.
ReservationRentalSelectionRevision must be the ubiquitous name for rental equipment and delivery-fee charge rows, with RentalDeliveryChargeLine as the single delivery-fee component. Payment handoff evidence: source-refs/sanmopia_web/application/controllers/api/Service.php:416-419 and source-refs/sanmopia_web/application/controllers/api/Service.php:531-534 reinsert posted rental ids before payment handoff; source-refs/sanmopia_web/application/models/Reservation_model.php:1231-1259 adds rental rows plus DELIVERY_FEE; and source-refs/sanmopia_web/application/models/Reservation_model.php:1318-1348 feeds rental totals into voucher service-balance or normal left-price payment amounts. Admin/export evidence: source-refs/sanmopia-admin/application/models/Reservation_model.php:216-229 reloads rental rows before PRICE_TABLE calculation, source-refs/sanmopia-admin/application/models/Reservation_model.php:584-595 joins RESERVATION_RENTAL_TB to LIST_RENTAL_TB, and source-refs/sanmopia-admin/application/models/Reservation_model.php:748-776 adds rental and delivery-fee values into admin price rows. Printable document evidence: source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:663-709 hardcodes rental names, breast-pump price, and delivery price into downpayment artifacts, while source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3914-3952 renders documents after loading the current rental catalog. Settlement evidence follows the same payment-row and board flow as add-options: source-refs/sanmopia-admin/application/models/Payment_model.php:198-278, source-refs/sanmopia-admin/application/models/Payment_model.php:384-523, and source-refs/sanmopia-admin/application/models/Payment_model.php:534-744. Remaining backend gap: persist ReservationRentalSelectionRevision and expose RentalSettlementImpactSnapshot, RentalDocumentChargeSnapshot, and RentalRefundRepairProjectionInvalidation so payment handoff, service-balance closeout, caregiver payout display, branch/HQ settlement, documents, refunds, and artifact repairs never re-read mutable rental ids, names, or delivery-fee constants.
ReservationCouponSelectionRevision must be the ubiquitous name for coupon selection rows; CouponUseLedgerEntry, CouponPaymentCloseoutFact, and CouponRefundRepairLedgerEntry own consumption, restoration, provider refund, settlement, and document impact. Payment evidence: source-refs/sanmopia_web/application/models/Reservation_model.php:1990-2033 deletes/reinserts coupon selections by PRERESERVATION_FL; source-refs/sanmopia_web/application/models/Payment_model.php:140-152 mutates USER_COUPON_TB.USE_FL during paid closeout; and source-refs/sanmopia_web/application/models/Payment_model.php:775-843 uses coupon-adjusted PRICE_TABLE values for pre-reservation payment, virtual account status, over-credit point grant, and shopping-mall coupon grant. Settlement evidence: source-refs/sanmopia-admin/application/models/Payment_model.php:3340-3405 joins RESERVATION_COUPON_USED_TB, USER_COUPON_TB, and PAYMENT_COUPON_TB into Danbee coupon payment rows; source-refs/sanmopia-admin/application/models/Payment_model.php:3410-3478 does the same for HQ/branch coupon rows; source-refs/sanmopia-admin/application/views/calculate_detail.php:629-660 and source-refs/sanmopia-admin/application/views/calculate_detail.php:1091-1127 render coupon payment and gift-fee checkbox lines; and source-refs/sanmopia-admin/application/models/Payment_model.php:534-744 writes BOARD_PAYMENT_* detail rows and marks coupon settlement flags. Refund evidence: source-refs/sanmopia_web/application/models/Coupon_model.php:530-553 and source-refs/sanmopia-admin/application/models/Coupon_model.php:935-958 reopen used coupons by mutable USE_FL plus free-text reuse logs; source-refs/sanmopia-admin/application/models/Coupon_model.php:164-188 refunds coupon payment through KCP and sets PAYMENT_COUPON_TB.REFUND_FL; and source-refs/sanmopia-admin/application/libraries/Kcppayment.php:31-44 sends full-cancel mod_type=STSC. Printable document evidence stays tied to mutable PRICE_TABLE and reservation reloads at source-refs/sanmopia-admin/application/models/Reservation_model.php:184-229, source-refs/sanmopia-admin/application/models/Reservation_model.php:731-790, and source-refs/sanmopia-admin/application/models/Reservation_model.php:871-916. Remaining backend gap: close the coupon path with immutable selection, use/restore/refund ledger entries, provider-refund idempotency key, settlement reversal lines, payout/document invalidation rows, and artifact repair/reissue lineage keyed by charge snapshot revision and payment fact revision.

Implementation note: backend 0644e7f exposes ReservationAddOptionSelectionRevisionPayload from successful booking-service-term side-effect assembly through application, API, and HTTP contracts. Backend e1846f8 persists that revision in sanmopia_reservation_add_option_selection_revisions with service-role-only RLS, direct lookup by revision key, finalized charge snapshot id, add-option charge links, and a full revision snapshot. Backend 4f7bebf now requires every BookingServiceTermAddOptionChargeLinkPayload to carry typed quantity_basis (effective_service_day, added_service_day, item_quantity, or source_component_total) plus non-empty quantity_basis_evidence_keys; revision persistence and HTTP responses retain both fields. Stage reservation ca44be7c-fbf3-4a4e-8e47-e27868bf2d72 reached settled with quantity_basis=added_service_day and evidence key extra/saturday/1 persisted. Backend 56413fe then makes occurrence ledger key/revision physical non-null revision columns, constrains their presence/equality in the JSON snapshot, and validates composite booking-ledger, assembly-lineage, and revision relationships. Revision keys include both occurrence-ledger and calendar-quote revisions; assembly delete is NO ACTION; an immutable trigger allows identical idempotent replay and rejects mutation. Stage reservation eeef7782-aff2-4065-bf9c-7ab48f7fd629 reached settled. This proves revision-level occurrence binding and immutability, not backend derivation of each quantity basis from ledger/policy, normalized per-charge-link rows, consumer-specific amount policy, historical backfill, printable document input, or refund/repair propagation. Backend 7c96fab wires that persisted revision into reservation financial lifecycle settlement closeout: branch/HQ settlement preparation accepts addOptionSelectionRevisionKey and addOptionSelectionRevisionNumber, and Supabase runtime rejects stale or missing references before mutating settlement state. Backend 70e0abd carries the paired revision reference through service-balance closeout command, event, current projection, and Supabase constraints. Backend a48172b propagates that closeout revision through caregiver payout service-balance slot state and persisted admin caregiver payout statement rows. Backend e00810e carries the same closeout revision into branch and HQ settlement issuance commands and validates it through the Supabase closeout reader before financial lifecycle mutation. The guarded positive-balance stage E2E reached settled for reservation 1a061d05-a590-4bc8-9a62-30dd03d7d9ac, proving one immutable revision across closeout, caregiver/admin payout, branch settlement, and HQ settlement issuance. Backend fbc60e4 now projects caregiver work-schedule service-balance shares from the frozen closeout event, caregiver receipt state, and payout instruction. Its versioned equal-slot policy supports multiple caregiver slots with deterministic integer allocation, and its reader has reservation-scoped lookup. Positive-balance stage reservation 0b57b5f1-12c5-42f0-bcdf-7ab90e469a8b reached settled with a frozen 25,000 KRW share. Backend 65a71ac closes the missing-writer gap by projecting accepted assignment decisions through CareTeamAssignmentProjectionWriter into sanmopia_reservation_caregiver_assignments. The projection resolves the candidate profile, member-to-auth binding, candidate grade, latest occurrence-ledger service-day count, and booking dates; replacement and clear decisions mark prior slots replaced or removed. Stage reservation 5dd549d3-6c2c-407c-b42a-fdcd7e769c6a persisted the roster row before payout and reached settled. Remaining roster risk is non-atomic decision-save/projection failure, durable repair or idempotent replay, and audited backfill for older accepted decisions, not absence of a projection writer. Contract b06f393 and backend f9f24aa now separate inbound addOptionChargeIntents from finalized charge links. Backend derives canonical quantity and evidence from the accepted service term, accepted price quote, occurrence ledger, catalog entry, and finalized charge line, then persists physical catalog/charge identifiers and child evidence rows through one atomic Supabase RPC. Canonical rows reject mutable occurrence, catalog, finalized-charge, and outbox changes; unresolved historical evidence is labeled legacy_unresolved instead of being presented as canonical. Stage reservation d1b8165d-e0da-497f-a55a-e9d6ecb6b924 reached settled with customer payable 150,000 KRW, caregiver payout 50,000 KRW, branch settlement 100,000 KRW, headquarters settlement 50,000 KRW, and service balance 25,000 KRW. Backend 3d411d2 then made reservation smoke cleanup repeatable without weakening those immutable rows: a private deployment identity and backend/transaction/exact reference guard authorize only the registered stage row. Registration-time catalog validation removed 50 invalid legacy cleanup references. Fresh stage reservation 655b6047-bd62-4315-bc40-d8714492aae2 registered zero invalid references and was reaped on the first attempt with 20 deleted rows; booking and workflow-request counts both returned zero afterward. Payment handoff, printable document, and refund/repair consumers remain open, so the add-option row remains Partial. Modern ubiquitous names to keep stable in backend contracts: ReservationAddOptionSelectionRevision, ReservationPaymentSettlementHandoffSnapshot, CaregiverPayoutChargeImpactSnapshot, BranchSettlementSeedProjection, HeadquartersSettlementSeedProjection, ReservationChargeDocumentSnapshot, and RefundRepairProjectionInvalidation.

Additional uncovered PHP consumers under the same owner rows:

Caregiver portal payout and service-balance receipt state need separate backend authority from settlement/payment completion. Source evidence: source-refs/sanmopia-manager/application/controllers/Reservation.php:36-77 accepts caregiver PUT requests for payment and sub_payment; source-refs/sanmopia-manager/application/models/Reservation_model.php:22-24 reads mutable reservation service-balance override fields into the caregiver reservation list; source-refs/sanmopia-manager/application/models/Reservation_model.php:65-69 reads PAYMENT_BRANCH_MANAGER_TB type 5 as reservation payout state; source-refs/sanmopia-manager/application/models/Reservation_model.php:247-270 joins customer service-balance payment rows and PAYMENT_BRANCH_MANAGER_TB type 3 into caregiver detail; source-refs/sanmopia-manager/application/models/Reservation_model.php:382-405 lets main/sub caregiver actions mutate PAYMENT_BRANCH_MANAGER_TB payment flags; and source-refs/sanmopia-manager/application/models/Reservation_model.php:488-515 reads main/sub salary rows from PAYMENT_BRANCH_MANAGER_TB and PAYMENT_BRANCH_SUB_MANAGER_TB. Modern ubiquitous names: CaregiverPortalPayoutStatusSnapshot, CaregiverServiceBalanceReceiptAcknowledgement, SubCaregiverServiceBalanceReceiptAcknowledgement, and CaregiverPayoutInstructionStatusProjection. Remaining backend gap: persist caregiver-facing receipt acknowledgements as actor-scoped events keyed by care-team recipient slot, service-balance closeout revision, payout instruction revision, expected payment fact revision, and branch/HQ settlement reference. Caregiver UI must request acknowledgement/disclosure only; it must not directly complete or repair PAYMENT_BRANCH_MANAGER_TB status rows.
Branch/HQ receivable settlement rows need explicit lineage from Danbee payment board facts and branch deposit acknowledgements. Source evidence: source-refs/sanmopia-admin/application/controllers/Calculate.php:150-223 posts branch/HQ settlement totals, selected reservation ids, payment types, coupon ids, membership/delivery/gift-fee flags, and free-form messages into insertPaymentDetail; source-refs/sanmopia-admin/application/models/Payment_model.php:575-603 creates or updates PAYMENT_ADMIN_BRANCH_TB receivable rows per reservation and payment type; source-refs/sanmopia-admin/application/models/Payment_model.php:607-650 marks normal/voucher payment rows as Danbee-settled; source-refs/sanmopia-admin/application/models/Payment_model.php:697-746 writes BOARD_PAYMENT_*_DETAIL_TB rows and marks Danbee coupon settlement flags; source-refs/sanmopia-admin/application/controllers/Calculate.php:248-263 turns branch deposit response into board status 2 complete or 4 arrears; source-refs/sanmopia-admin/application/models/Payment_model.php:2039-2053 reads BOARD_PAYMENT_ADMIN_DETAIL_TB joined to PAYMENT_ADMIN_BRANCH_TB; source-refs/sanmopia-admin/application/models/Payment_model.php:3339-3405 and source-refs/sanmopia-admin/application/models/Payment_model.php:3410-3478 project coupon settlement separately for Danbee and HQ/branch; and source-refs/sanmopia-admin/application/models/Payment_model.php:4241-4262 exposes a repair scan for missing PAYMENT_ADMIN_BRANCH_TB rows while source-refs/sanmopia-admin/application/models/Payment_model.php:4265-4289 mutates board detail/coupon completion flags. Modern ubiquitous names: DanbeeSettlementPaymentBoardFact, BranchSettlementReceivablePaymentState, HeadquartersSettlementDepositAcknowledgement, SettlementBoardDetailCompletionFact, and SettlementReceivableRepairDecision. Remaining backend gap: persist a single settlement board ledger that links reservation payment facts, coupon payment facts, ReservationAddOptionSelectionRevision, rental/coupon selection revisions, branch receivable rows, branch deposit acknowledgements, arrears decisions, and repair decisions. Branch/HQ/Danbee projections and printable or refund/repair consumers must reference those ledger ids instead of posted arrays, mutable board flags, or missing-row scans.
Active data-room list, detail, and export projections need one immutable amount basis and classification snapshot. Source evidence: source-refs/sanmopia-admin/application/models/Payment_model.php:1595-1658 rebuilds archived Danbee voucher/normal/completed counts from current reservation service-type and status rows while source-refs/sanmopia-admin/application/views/table/data_room/table_calculate_danvi.php:29-49 displays those rebuilt counts beside persisted board totals; source-refs/sanmopia-admin/application/models/Payment_model.php:1750-1912 makes branch/HQ ALL_PRICE mean outstanding components for board statuses 0/1/3/4, but all original components after status 2, and also reloads the monthly membership price from mutable branch policy; source-refs/sanmopia-admin/application/views/table/data_room/table_calculate_central.php:46-60 renders both meanings under the same component and total columns; source-refs/sanmopia-admin/application/controllers/Common.php:132-150 opens branch data-room detail with a board id but null period dates; source-refs/sanmopia-admin/application/models/Payment_model.php:1357-1436 derives a period from those null dates, then re-joins the membership override while hydrating the historical board; and source-refs/sanmopia-admin/application/models/Payment_model.php:1495-1551 rebuilds voucher and gift-coupon subtotals from current payment/coupon rows. Danbee export then calls the same live detail loader and recalculates payment method fees at source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3741-3900. Modern ubiquitous names: SettlementStatementAmountBasisSnapshot, SettlementArchiveClassificationSnapshot, SettlementProjectionConsistencyDecision, and SettlementProjectionDiscrepancyRepair. Status: Partial; frozen statement, dataset, and artifact foundations exist, but active data-room adapters still rebuild historical meaning from mutable rows. Invariant: each statement revision must expose separately named gross, acknowledged, outstanding, fee, and net amounts plus frozen reservation classification and component subtotal checksums. State transitions may select a displayed amount but must never change one field’s meaning. List, detail, and export must share the same statement/dataset revision and checksum; mismatch blocks artifact issuance and creates an auditable repair case that preserves source-observed values.
Service-balance import needs formula provenance because legacy source behavior contradicts its own stated additional-service-day basis. Source evidence: source-refs/sanmopia-admin/application/models/Payment_model.php:4196-4203 adds Saturday/holiday quantities to dayCount and charges those rows once; source-refs/sanmopia-admin/application/models/Payment_model.php:4205-4219 then says other additional services use total days plus those added days, but resets dayCount to voucher service days or normal weeks times five before multiplying each non-Saturday/non-holiday row, discarding the earlier added-day count; source-refs/sanmopia-admin/application/models/Reservation_model.php:1572-1575 recalculates that amount from current price/add-option rows during operator payment save; source-refs/sanmopia-admin/application/models/Reservation_model.php:1641-1677 writes it into the type 3 service-balance payment row; and source-refs/sanmopia-admin/application/models/Reservation_model.php:3507-3545 derives caregiver receipt state from that row, including automatic completion when the amount is zero. The same mutable payment amount then reaches Danbee and branch/HQ settlement readers documented above. Modern ubiquitous names: ServiceBalanceAdditionalServiceChargeDecision, ServiceBalanceSourceFormulaEvidence, and ServiceBalanceCalculationDiscrepancyRepair. Status: Partial; the modern additional-service charge policy and service-balance closeout references exist, but historical type 3 rows do not record which source formula produced them. Import must preserve source amount, source formula variant, price/add-option revision evidence, and discrepancy amount without silently rewriting history. Canonical recomputation or an approved repair must invalidate and rebuild caregiver payout, Danbee settlement, branch settlement, HQ settlement, and printable artifact projections from one new service-balance revision.

Additional active consumers prove more source formula variants. Customer and admin reservation price projections add Saturday/holiday quantities to the effective service-day multiplier but treat add-option labels containing Wanju as one-time amounts at source-refs/sanmopia_web/application/models/Reservation_model.php:1123-1162 and source-refs/sanmopia-admin/application/models/Reservation_model.php:649-695. Caregiver reservation projection instead adds a computed week count for Saturday presence, adds holiday quantity, and still treats Wanju as one-time at source-refs/sanmopia-manager/application/models/Reservation_model.php:185-220. Caregiver payout multiplies every non-Saturday/non-holiday option, including Wanju, by service days plus added-day quantities at source-refs/sanmopia-manager/application/helpers/salary_helper.php:109-145. Caregiver schedule view repeats that recurring formula, adds normal base-price difference, then divides the result by caregiver count at source-refs/sanmopia-manager/application/views/schedule/schedule_info.php:169-200. Printable downpayment rendering also multiplies every non-Saturday/non-holiday option by service days plus added days at source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:647-660. Modern invariant: every AdditionalServiceChargeComponent in ReservationAddOptionSelectionRevision must freeze explicit quantity_basis (effective_service_day, added_service_day, item_quantity, or source_component_total), occurrence references, regional-benefit decision, policy revision, and consumer purpose. Customer charge, service-balance, caregiver compensation, and document lines may have distinct policy amounts, but all must reference the same accepted selection and occurrence revisions; no consumer may infer recurrence, Wanju treatment, added-day count, or care-team allocation from Korean labels. Danbee, branch, and HQ settlement consume finalized lines and closeout lineage only. Backend 4f7bebf now validates the four typed quantity bases, rejects empty basis-evidence sets, and retains both fields through selection-revision persistence and HTTP response. Stage reservation ca44be7c-fbf3-4a4e-8e47-e27868bf2d72 persisted added_service_day with evidence key extra/saturday/1 and reached settled. Backend 56413fe now proves revision-level occurrence binding with physical non-null ledger key/revision columns, JSON equality checks, validated composite foreign keys, occurrence-plus-calendar revision identity, NO ACTION assembly retention, and immutable idempotent replay. Stage reservation eeef7782-aff2-4065-bf9c-7ab48f7fd629 reached settled. Status remains Partial: basis metadata is still supplied rather than derived from ledger and policy, per-charge-link rows are not normalized, and consumer-specific amount policies remain unproven. a48172b and e00810e prove closeout revision propagation through payout and branch/HQ issuance, while payment handoff, printable document input, refund/repair propagation, historical formula-variant backfill, and discrepancy repair remain unproven. Migration traps for caller-derived basis, JSON-contained per-link lineage, per-link application-emulated integrity, and mutable post-payment values remain tracked under existing owner SFC-20260708-CUR-065.
Add-option payment, printable, and refund consumers still lack immutable formula lineage. The customer payment action loads userFeeSecurityPrice from the current reservation PRICE_TABLE at source-refs/sanmopia_web/application/controllers/Service.php:666-679, writes that amount into the KCP form at source-refs/sanmopia_web/application/views/service/reservation_payment.php:138-145, and launches the provider from browser form state at source-refs/sanmopia_web/static/js/reservation_payment.js:40-89; the callback then reloads the reservation and independently uses the current userFeeSecurityPrice for the provider command and local payment rows at source-refs/sanmopia_web/application/controllers/api/Payment.php:89-165 and source-refs/sanmopia_web/application/models/Payment_model.php:198-226. Printable agreement/downpayment generation parses display strings and Korean labels into cells, reruns the added-day multiplier, and recomposes totals from mutable reservation rows at source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:417-465, :647-660, :711-725, and :731-779. Full cancellation scans provider-context payment rows, issues opaque full refunds, marks each successfully cancelled row refunded, and restores coupon state as a separate side effect at source-refs/sanmopia_web/application/models/Payment_model.php:383-440 and source-refs/sanmopia_web/application/models/Reservation_model.php:989-1035; no reversed add-option component or selection revision is retained there. Admin cancellation exposes a separate failure mode: it commits reservation status before provider refund work at source-refs/sanmopia-admin/application/models/Reservation_model.php:1769-1800, classifies every selected payment row with hardcoded IFNULL('일반', '바우처') at :1827-1835, ignores the provider refund result before marking the inferred local table row refunded at :1838-1857, then refunds one change-payment context and restores coupons at :1861-1880 without add-option component, payment-fact revision, or document-artifact invalidation lineage. Modern invariant: ReservationPaymentSettlementHandoffSnapshot must freeze the accepted ReservationAddOptionSelectionRevision, finalized charge snapshot, exact provider amount, and payment fact revision before provider launch; the callback must reject mismatched references instead of re-reading current price formulas. ReservationChargeDocumentSnapshot must consume the same frozen component references and selection revision without label parsing or amount recomputation. RefundRepairProjectionInvalidation and existing settlement reversal lines must identify the original payment/charge revisions and exact frozen components reversed, then invalidate or reissue affected settlement and printable artifacts. Provider result must gate local refunded state, payment fact must select service type/storage target, and cancellation/coupon restoration must wait for the refund completion barrier. Status remains Partial: none of these legacy consumers proves add-option payment handoff, printable artifact, or refund/repair lineage.

2026-07-10 persistent legacy payment miner delta

Existing payment, refund, virtual-account, cash-receipt, and repair rows remain canonical. These rows add only source requirements not stated by those owners. Legacy controller order, array truthiness, provider payloads, and terms text are evidence; target authority stays in backend commands, ledgers, policies, and repair projections.

feature_id	priority	lane_owner	source_evidence	ddd_aggregate	command_query	persistence	contract	e2e_proof	status	backend_owned_design
`SFC-20260710-PAY-001`	P0	Backend / `pricing_settlement`	Legacy browser amount and late ownership checks at `source-refs/sanmopia_web/static/js/mypage/reservation_changePayment.js:43-66`, `source-refs/sanmopia_web/application/controllers/api/Payment.php:657-713`, and destructive unpaid replacement at `source-refs/sanmopia_web/application/models/Payment_model.php:856-874`.	`PaymentChangeHandoffContext`, `PaymentChangeAdjustment`, `PaymentProviderHandoffSession`, `PaymentChangeSupersessionFact`	`PrepareAuthorizedPaymentChangeHandoffCommand`, `AuthorizeAndPreRegisterPaymentChangeCommand`, atomic unpaid replacement	Atomic handoff RPC is reached by public runtime. Backend derives booking context, mother, amount, product plan, Kill Bill route, payment key, revisions, expiry, evidence, and return route. `PAY_PAYMENT_CHANGE` separates stage/SpiceDB policy from pre-reservation payment. Exact replay avoids duplicate provider calls. A second atomic RPC locks booking, permits replacement only while provider payment is `waiting`, supersedes old handoff, cancels old adjustment, inserts replacement, and appends lineage without deleting evidence.	Request accepts only `selectedPaymentMethodCode`; `Idempotency-Key` and Supabase bearer required. Contract rejects browser mother/payment/provider/amount/authority fields.	Secure handoff proof: booking `9c19e1c3-9b64-41b3-bb2b-67517e08920a`, adjustment `665ff856-a041-4b51-be40-b4c12165ffac`. Atomic replacement proof: booking `bcf1db59-9c44-47c1-aa6e-6aacafd79cba`, old `c5d89751-1544-4b32-900f-86e112dedfe2`, replacement `e13e961e-6ab4-4245-8e1b-cf2fe8c25483`; verified old-cancel/new-active, handoff supersession, lineage, retained waiting payment, and reaper.	`e2e_proven`	Browser selects allowed method only. Backend owns all financial and authority facts. Paid or unknown provider operations cannot be replaced here; PAY-006 reconciliation/compensation resolves them. See ADR-025.
`SFC-20260710-PAY-002`	P0	Backend / `pricing_settlement`	Normal virtual-account issue sends account/deadline instructions before local payment persistence at `source-refs/sanmopia_web/application/controllers/api/Payment.php:126-180`. Coupon, balance, and pre-reservation issue handling mutates waiting state at `source-refs/sanmopia_web/application/controllers/api/Payment.php:421-457`, ignores the coupon update result from `source-refs/sanmopia_web/application/models/Payment_model.php:472-475` and the unchecked balance/pre-reservation updates at `source-refs/sanmopia_web/application/models/Payment_model.php:353-380`, then dispatches instructions and returns success at `source-refs/sanmopia_web/application/controllers/api/Payment.php:470-501`. Payment-change virtual-account issue writes `PAYMENT_CONTEXT`, sets `DEPOSIT_DT`, and sends completion notices at `source-refs/sanmopia_web/application/controllers/api/Payment.php:706`, `source-refs/sanmopia_web/application/controllers/api/Payment.php:723`, `source-refs/sanmopia_web/application/controllers/api/Payment.php:740`, and `source-refs/sanmopia_web/application/models/Payment_model.php:893`. Pre-reservation issue/deposit effects mutate reservation/coupon/credit state at `source-refs/sanmopia_web/application/models/Payment_model.php:745`, `source-refs/sanmopia_web/application/models/Payment_model.php:758`, `source-refs/sanmopia_web/application/models/Payment_model.php:784`, and `source-refs/sanmopia_web/application/models/Payment_model.php:825`. Deposit completion notices fan out by product at `source-refs/sanmopia_web/application/models/Payment_model.php:574`, `source-refs/sanmopia_web/application/models/Payment_model.php:579`, `source-refs/sanmopia_web/application/models/Payment_model.php:588`, `source-refs/sanmopia_web/application/models/Payment_model.php:597`, `source-refs/sanmopia_web/application/models/Payment_model.php:623`, `source-refs/sanmopia_web/application/models/Payment_model.php:636`, and `source-refs/sanmopia_web/application/models/Payment_model.php:721`.	`VirtualAccountIssuanceCommitBarrier`, `VirtualAccountPaymentLifecycle`, `OrphanedVirtualAccountIssueRepairCase`, `VirtualAccountInstructionDispatchOutbox`, `PaymentChangeVirtualAccountLifecycle`, `PreReservationPaymentCloseout`, `VirtualAccountDepositCompletionNotificationOutbox`	`CommitVirtualAccountIssueCommand`, `DispatchVirtualAccountInstructionCommand`, `ReconcileOrphanedVirtualAccountIssueCommand`, `CommitPaymentChangeVirtualAccountIssueCommand`, `MarkPaymentChangeVirtualAccountDepositedCommand`, `ApplyPreReservationVirtualAccountDepositEffectsCommand`, `DispatchVirtualAccountDepositCompletionNotificationsCommand`	Backend `5c66e2d` adds provider-order/deadline issue replay protection to the persisted lifecycle decision: an exact replay is non-mutating and emits no second instruction, while mismatched or post-deposit issue events are rejected. Backend `96f8849` wires `KillBillPaymentEventIngestionHandler` to persist a `mark_deposited` `VirtualAccountPaymentLifecycleDecision` through `SupabaseVirtualAccountPaymentLifecycleDecisionStore` when a paid Kill Bill callback closes a virtual-account payment. Backend `eed2fe0` adds the application commit barrier: `CommitVirtualAccountIssueHandler` computes the lifecycle decision, builds the provider-neutral instruction outbox entry only for `open_waiting_payment`, and calls `VirtualAccountIssueCommitStore` before returning customer-instruction readiness. Backend `563e783` implements the Supabase RPC behind that port: it upserts the lifecycle decision, checks and advances `sanmopia_payment_records.payment_fact_revision`, inserts `sanmopia_virtual_account_instruction_dispatch_outbox`, rejects dispatch for non-mutating issue decisions, and was applied to stage. Backend `e8b38b6` adds `OrphanedVirtualAccountIssueRepairCase`, planning/persistence ports, and service-role Supabase storage for provider-issued/local-write-failed, payment revision mismatch, instruction outbox rejection, and provider issue without local fact. Backend `9240cee` adds `VirtualAccountInstructionDispatchWork`, retry result contracts, a backend worker handler, Supabase claim RPC `sanmopia_claim_virtual_account_instruction_dispatches`, retry timestamps, attempt count, and provider dispatch reference persistence without reissuing provider accounts. Backend `713f880` adds `SupersededVirtualAccountDepositAlias`, planning/persistence ports, and service-role Supabase storage for deposits reported through superseded provider orders without marking the active payment paid. Backend `3152321` wires Kill Bill virtual-account deposit callbacks to read the backend-frozen active provider order, auto-capture superseded-order deposits as aliases, and block payment workflow start for mismatched provider orders. Backend `38aac56` adds an executable orphaned-issue repair worker: open repair cases are claimed through Supabase, local commit reconciliation is run, stale provider accounts are closed or instruction dispatch is rescheduled, and terminal status plus resolution evidence is persisted. Backend `3df31d0` splits payment-change virtual-account flow: issue events persist waiting lifecycle only, deposit events mark adjustment paid, freeze provider evidence, and trigger settlement continuation; stage constraints now accept `payment_change_adjustment` across virtual-account lifecycle tables. Backend `60760f9` adds `PreReservationDepositCloseout`, `ApplyPreReservationVirtualAccountDepositEffectsCommand`, idempotent closeout store port, and post-commit reservation transition requester so coupon credit, reservation payment credit, over-credit grants, and reservation transition keys are backend-planned from deposited lifecycle facts. Backend `0d44d0d` adds service-role Supabase persistence for `sanmopia_pre_reservation_deposit_closeout_plans`, RLS, append-only insert adapter, duplicate request-key guard, stage migration, and adapter tests under the payment_conversion owner slice. Backend `7edb5ea` adds `VirtualAccountDepositCompletionDispatchPlanCommand`, mapping deposited virtual-account facts to product-specific `PlanPaymentCommunicationDispatchCommand` routes for pre-reservation, customer-share deposit/balance, and gift-coupon purchase.	Issue result binds payment id/revision, provider account reference, frozen amount/deadline, product purpose, recipient snapshot, provider attempt, instruction outbox key, and dispatch idempotency key before customer success. Deposit callback lifecycle facts bind provider event, provider transaction, payment revision, purpose, and backend evidence keys before payment workflow start. Orphan repair cases bind provider event, provider order, amount, deadline, failed decision/outbox keys, source evidence, reason, status, and recommended reconciliation/provider-close/dispatch-retry actions. Dispatch work binds outbox key, idempotency key, payment record, purpose, provider transaction, amount/deadline, recipient snapshot, evidence keys, attempt count, next retry time, and provider dispatch reference. Superseded alias binds active payment, optional superseded payment, active and superseded provider orders, amount, deposit time, detected time, reason, status, and evidence keys.	Colocated policy and migration tests prove replay revision and notification invariants; the stage decision constraint accepted the new replay action. Focused callback tests prove `vcnt` paid callbacks write a deposited lifecycle decision and production composition injects the Supabase store. Backend `eed2fe0` colocated application tests prove new issue commit creates a dispatch instruction only after store commit, exact replay and stale provider-order cases commit no dispatch, non-issue events are rejected, and store failure returns no customer instruction. Backend `563e783` adapter/migration tests prove RPC payload shape, outbox table/RLS/grants, payment revision guard, and ambiguity fix. Backend `e8b38b6` tests prove orphan repair reason/action selection, non-issue rejection, handler persistence, adapter row shape, service-role table grants, and stage migration `20260713001000_orphaned_virtual_account_issue_repair_cases.sql`; `pnpm supabase:db:lint:stage` returned no schema errors. Backend `9240cee` focused tests prove dispatch success, retry scheduling, mismatched dispatch result failure, Supabase RPC claim mapping, completed/failed outbox updates, retry migration `FOR UPDATE SKIP LOCKED`, `attempt_count`, and service-role execution grant. Backend `713f880` focused tests prove superseded deposit alias creation, same-order rejection, non-deposit rejection, adapter row shape, table RLS/grants, provider-order difference constraints, stage migration `20260713003000_superseded_virtual_account_deposit_aliases.sql`, `uv run pytest ...virtual_account_payment_lifecycle -q`, Ruff, Tach, `pnpm supabase:db:push:stage -- --dry-run`, `pnpm supabase:db:push:stage`, and `pnpm supabase:db:lint:stage` passed. Backend `3152321` tests prove frozen active provider-order reads, superseded-order callback alias capture without lifecycle decision or workflow start, adapter active-order lookup, runtime composition wiring, `uv run pytest ...killbill_payment_event_test.py ...main_test.py -q`, Ruff, and Tach. Backend `38aac56` tests prove provider-close repair execution, dispatch-retry repair execution, failed-action open-case retention, Supabase claim/status mapping, migration claim RPC, focused lifecycle pytest, Ruff, Tach, stage dry-run, stage push, and stage lint. Backend `3df31d0` tests prove payment-change issue waits without paid receipt, deposit marks paid and continues settlement, replay deposit avoids rewrite, purpose catalog includes `payment_change_adjustment`, Supabase migration guards, focused pytest, Ruff, Tach, stage dry-run, stage push, stage lint, and direct stage constraint inspection. Backend `60760f9` tests prove pre-reservation deposit closeout plans reservation payment credit, coupon credit consumption, over-credit grant ledgers, transition request keys, idempotent replay, rejected non-pre-reservation payments, and Tach-safe payment_conversion boundaries. Backend `0d44d0d` tests prove Supabase row shape, no blind upsert, existing-plan read, duplicate request-key rejection, migration columns, RLS, service-role-only write grants, focused pytest, Ruff, Tach, stage dry-run, stage push, stage lint, and direct stage table/grant inspection. Backend `7edb5ea` tests prove pre-reservation mother/payer/branch/secondary-contact routes, customer-share mother/payer routes, gift-coupon payer plus receiver direct-contact routing, receiver contact validation, unsupported product rejection, focused pytest, Ruff, and Tach. Backend stage proof `pnpm supabase:smoke:stage:virtual-account-product-lifecycle` creates rollback-scoped waiting `vcnt` payments for pre-reservation, customer-share deposit, customer-share balance, gift-coupon, and payment-change products against an existing stage booking, commits each issue through `sanmopia_commit_virtual_account_issue`, verifies payment revision `2` plus pending instruction outbox, records deposited lifecycle decisions, advances payment facts to approved revision `3`, persists the pre-reservation `apply_deposit_effects` closeout plan tied to its deposit decision, verifies pre-reservation, customer-share, gift-coupon, and payment-change completion workflow routes, then rolls back.	`e2e_proven`	Backend `5c66e2d` prevents an exact accepted-issue replay from advancing payment revision or redispatching instructions. Backend `96f8849` makes virtual-account deposit callbacks produce lifecycle facts instead of only payment workflow facts. Backend `eed2fe0` moves customer instruction readiness behind a backend-owned commit port. Backend `563e783` persists lifecycle decision, local waiting payment fact revision, and instruction outbox in one Supabase transaction before customer success. Backend `e8b38b6` gives provider-issued/local-write-failed paths a durable repair record instead of silent best-effort close/refund behavior. Backend `9240cee` makes instruction dispatch independently retryable, worker-safe, and evidence-bearing without opening another virtual account. Backend `713f880` preserves superseded-account deposit evidence instead of mutating the active payment from a mismatched provider order. Backend `3152321` enforces that rule in Kill Bill callback ingestion by consulting frozen backend lifecycle facts before workflow start. Backend `38aac56` turns orphan repair from passive evidence into an executable backend worker with Supabase claim, action ports, and resolution evidence. Backend `3df31d0` prevents payment-change virtual-account issue from being treated as paid money and moves paid transition to deposit callback. Backend `60760f9` moves pre-reservation deposit side-effect planning behind a backend command and idempotency gate instead of UI/model mutation. Backend `0d44d0d` makes that closeout durable in Supabase with RLS and stage proof. Backend `7edb5ea` moves product-specific deposit-completion notice fan-out into backend-owned planning over the existing communication dispatch outbox. Backend stage smoke now proves virtual-account issue, deposit, payment-fact closeout, completion-route readiness for all modeled product purposes, and gift-coupon paid-checkout side effects through issued entitlement, fulfillment request, receiver fulfillment route, and frozen settlement template without frontend authority. Remaining work is live Kill Bill-originated provider proof plus durable workflow/API execution for gift-coupon closeout and settlement invalidation.
`SFC-20260710-PAY-003`	P0	Backend / `payment_processing`	The KCP callback logs raw POST, reads `noti_id`, and invokes deposit handling at `source-refs/sanmopia_web/application/controllers/api/Kcp.php:48-100`; the log has no uniqueness or decision state at `source-refs/sanmopia_web/application/models/Kcp_model.php:8-13`. Deposit handling dedupes only through current paid state at `source-refs/sanmopia_web/application/models/Payment_model.php:532-536`, while the first execution mutates payment/reservation state and sends notices at `source-refs/sanmopia_web/application/models/Payment_model.php:539-651` or issues coupon entitlement and notices at `source-refs/sanmopia_web/application/models/Payment_model.php:707-731`.	`ProviderWebhookInboxEvent`, `ProviderWebhookBusinessEffectDecision`, `ProviderWebhookConflictRepairCase`	`IngestProviderWebhookCommand`, `ApplyVirtualAccountDepositEffectsCommand`, `ReplayProviderWebhookEffectsCommand`	Backend `31e5d83` runtime-wires official Kill Bill ExtBusEvent verification, queue processing, service-role event persistence, operation/status mapping, and strict DB evidence. Backend `072b2e0` adds canonical payment fingerprint reuse plus one atomic Supabase RPC for inbox insert and PGMQ send. Same identity plus same digest increments replay evidence without requeue; different digest appends a repair-pending quarantine row without overwriting or processing the canonical event. Per-effect replay state remains unproven.	Inbox identity is provider plus provider event id; payload digest, provider transaction, payment revision, amount, event time, and effect idempotency keys are backend-only contract fields.	Synthetic stage proof passes first-delivery queueing, formatting-only duplicate replay, changed-amount quarantine, repeated-conflict observation counting, one-message worker execution, zero-message duplicate dispatch, and canonical-row immutability. Missing live Kill Bill-originated callback and partial-effect retry E2E proof.	`runtime_wired`	Backend `072b2e0` durably inserts the inbox event and PGMQ message in one transaction before acknowledgement. Same identity plus same digest returns `duplicate`; same identity plus different digest returns `quarantined`, opens repair evidence, and applies nothing. Remaining work gives payment closeout, reservation transition, coupon issuance, cash-receipt evidence, and notices stable effect keys so retries resume missing effects without repeating completed ones.
`SFC-20260710-PAY-004`	P0	Backend / `pricing_settlement`	Payment terms distinguish app-paid reservation/customer-share charges from service balance paid directly to the caregiver, and state that company and caregiver cannot issue a receipt for that direct service balance at `source-refs/sanmopia_web/application/views/about/terms.php:159-164`. Runtime UI preserves that distinction: `본인부담 잔금` uses KCP at `source-refs/sanmopia_web/static/js/mypage/reservation.js:608-693`, while `서비스 잔금` only displays caregiver and substitute-caregiver bank accounts at `source-refs/sanmopia_web/static/js/mypage/reservation.js:695-737`; reservation detail repeats direct caregiver payment by cash or transfer at `source-refs/sanmopia_web/application/views/mypage/reservation_detail.php:476-480`. KCP handoff applies one configured site identity and generic product name `산모피아` to provider-collected products at `source-refs/sanmopia_web/application/views/item/kcp/order_info_form.php:35-55`, but does not carry a frozen payment-product or merchant-of-record discriminator. Generic completion form carries only cash-receipt request flag and purpose at `source-refs/sanmopia_web/application/views/item/kcp/pay_form.php:15-19`; no production form supplies `cash_id_info`. Customer receipt UI includes only reservation/customer-share payments, then always constructs KCP `card_bill` URL even when stored payment used bank transfer or virtual account at `source-refs/sanmopia_web/application/views/mypage/reservation_receipt.php:50-75` and `source-refs/sanmopia_web/application/views/mypage/reservation_receipt.php:85-127`.	`PaymentProductCashReceiptPolicy`, `ReservationPaymentCashReceiptEligibilitySnapshot`, `PaymentProviderHandoffSession`, `PaymentProviderCashReceiptEvidence`, `PaymentCashReceiptTaxEvidenceTimeline`	`PreRegisterReservationPaymentCommand`, `ReservationPaymentProviderHandoffIntent`, `KillBillPaymentEventIngestionHandler`, `ProjectCurrentCustomerReceiptTaxEvidenceArtifactCommand`, `ProjectCurrentSettlementTaxEvidenceDatasetRevisionCommand`	Versioned product catalog owns merchant, collection channel, receipt issuer, eligibility, supported purposes, and denial reason. Payment pre-registration resolves one plan, rejects requested caregiver-direct receipt before gateway call, freezes request plus decision, and requires exact replay. Supabase RPC atomically persists actor, fee, cash-receipt, and provider-handoff snapshots while independently checking product policy and frozen handoff facts. Typed reservation provider handoff carries frozen amount, method, route, expected payment revision, expiry, idempotency key, source evidence, and fingerprint. Callback parses provider evidence once and persists frozen purpose plus vault identity rather than callback authority. Missing authority or purpose/identity/approval mismatch rejects tax evidence into `reconciliation_required` while accepted payment closeout continues, preventing cash-evidence faults from triggering full-payment compensation. Backend evidence timeline lists all append-only evidence for a payment, selects the current customer-visible artifact source, and emits all exportable approval/reversal rows for settlement tax datasets.	Strict pre-registration accepts payment id plus request state, purpose, and vault identity reference. Contract removed browser reservation, amount, method, purpose, plan, merchant, issuer, eligibility, provider authority, return URL, and provider payload authority. Response exposes immutable actor, fee, cash-receipt decision, and backend-owned handoff session snapshots. Provider callback may add approval/transaction/order evidence only.	Backend focused 62 tests, Ruff, Tach; stage migrations via `pnpm supabase:db:push:stage`; stage checkout handoff smoke, hosted customer receipt smoke, hosted settlement tax-export smoke, policy smoke, atomic accepted snapshot rollback proof, forged merchant-policy rejection, transactional reconciliation-status proof, reversal lineage proof, and focused artifact/tax-evidence timeline tests. Missing live Kill Bill-originated callback and live provider-originated reversal.	`runtime_wired`	Checkout/plugin and callback consume frozen snapshot, never recompute catalog policy. Refund/reversal retains original merchant policy. Receipt and tax-export projections consume backend-selected evidence timeline so customer UI cannot keep exposing stale approval after reversal. See ADR-026.

PAY-004 reversal follow-up on 2026-07-12: backend appends provider_refund_reversal evidence only from a successful refund ledger result, latest approved receipt evidence, frozen eligibility snapshot, and explicit provider cash-reversal reference. Missing facts enter cash_receipt_evidence_status=reconciliation_required; refund completion remains recorded without inventing tax reversal. Supabase backfills eligibility snapshot ids onto modern evidence, exposes service-role latest-approved lookup, permits the reversal evidence source, and enforces policy-lineage presence. Production Kill Bill composition now injects the Supabase evidence store/reader. Focused 58 tests, Ruff, Tach, main import, stage migration/lint/typegen, and rolled-back original-to-reversal lineage proof pass. Remaining reversal gap is live provider callback proof, not backend lineage implementation.

PAY-004 receipt/tax-export follow-up on 2026-07-12: backend added PaymentCashReceiptTaxEvidenceTimeline, ProjectCurrentCustomerReceiptTaxEvidenceArtifactCommand, ProjectCurrentSettlementTaxEvidenceDatasetRevisionCommand, and a Supabase payment-scoped evidence list reader. Customer receipt artifact selection now chooses the latest customer-visible approval/reversal evidence from all append-only rows for the payment; settlement tax export receives all exportable approval and reversal lines with source evidence lineage. Focused tests prove a refund reversal replaces stale customer approval exposure and settlement export keeps approval-plus-reversal lineage.

PAY-004 hosted receipt follow-up on 2026-07-12: backend added authenticated route GET /customer-receipt-tax-evidence-artifacts/{reservationBookingId}. The route requires Supabase bearer token, rejects withdrawn users, checks SpiceDB view_receipt on the reservation booking before reading payment evidence, and returns only customer-safe artifact fields from backend-selected evidence timeline. Focused HTTP tests prove reversal selection, provider reference redaction, missing bearer rejection, and SpiceDB denial before Supabase evidence read.

PAY-004 hosted settlement tax-export follow-up on 2026-07-12: backend added authenticated route GET /settlement-tax-evidence-dataset-revisions/{datasetRevisionId}. The route requires Supabase bearer token, rejects withdrawn users, checks SpiceDB settle for branch scope or review_hq_settlement for headquarters scope before reading payment evidence, and returns backend-selected approval plus reversal dataset lines with checksum and source evidence lineage. UI callers cannot choose rows, recompute export totals, or receive provider payment/order/transaction references. Focused HTTP tests prove branch authorization, headquarters authorization, approval-plus-reversal lineage, provider reference redaction, missing bearer rejection, and denial before evidence read.

PAY-004 hosted settlement tax-export stage proof on 2026-07-12: pnpm supabase:smoke:stage:settlement-tax-evidence-route created booking f6931f0c-1eaf-4cb8-a45a-7485c47934a4, seeded payment stage-tax-evidence-payment-20260712122749-8c31df28, called the hosted dataset route as the branch operator and headquarters administrator, verified both scopes returned two approval/reversal lines without provider references, and reaped stage-reservation-booking:f6931f0c-1eaf-4cb8-a45a-7485c47934a4 with SpiceDB cleanup verification. Remaining PAY-004 proof is hosted checkout/plugin binding and live Kill Bill-originated callback.

PAY-004 reservation checkout handoff stage proof on 2026-07-12: pnpm supabase:smoke:stage:reservation-payment-handoff-session created booking 113d0182-a79d-471d-a66b-d7183b053298, pre-registered payment 113d0182a79d471da66bd7183b053298, verified response handoff reservation-payment-handoff:113d0182-a79d-471d-a66b-d7183b053298:113d0182a79d471da66bd7183b053298:0, verified exact replay kept the same handoff key/fingerprint, verified Supabase persisted provider_key=killbill, state=prepared, and expected_payment_revision=0, and reaped the stage batch with SpiceDB cleanup verification. Remaining PAY-004 proof is live Kill Bill-originated callback through the restricted admission route.

PAY-004 hosted Kill Bill callback stage proof on 2026-07-12: pnpm supabase:smoke:stage:killbill-payment-event-callback created booking 06bb3c50-aca5-4ab4-97e2-fd8a955729a6, pre-registered payment 06bb3c50aca54ab497e2fd8a955729a6, posted a signed official-shape PAYMENT_SUCCESS ExtBus callback, verified persisted inbox event killbill-event:sha256:3af8a2681cbb1d12985bf4eda20e0ede5e162efa50e9930b5e9d66d52165d08f, verified one queued sanmopia_payment_webhook_processing message 7, verified duplicate replay did not requeue work, dispatched the payment-webhook worker, verified the worker archived message 7, verified completed Restate workflow killbill:PAYMENT_SUCCESS:06bb3c50aca54ab497e2fd8a955729a6:stage-killbill-tx-20260712131444-9f9a82b5, verified the payment record became approved with deposited_at, and reaped the stage batch with SpiceDB cleanup verification. Remaining PAY-004 proof is trusted Traefik/provider-originated callback deployment and live provider-originated reversal.

PAY-004 callback-to-settlement stage proof on 2026-07-12: pnpm supabase:smoke:stage:killbill-callback-to-settlement-completion created booking b681a97a-3bb9-4e00-887d-c50d3799ef23, approved payment b681a97a3bb94e00887dc50d3799ef23 through Kill Bill callback event killbill-event:sha256:1aef72c067a736ae2bbbd3fcdb13e0efe2bdb1c35d3234093f4f397da22d001a, continued payment workflow killbill:PAYMENT_SUCCESS:b681a97a3bb94e00887dc50d3799ef23:stage-killbill-tx-20260712141353-8b4ed89b, recorded service delivery, issued caregiver payout instruction ec4f5565-8a01-57bf-b830-35e1e0a193b6, recorded branch payout deposit, prepared branch and headquarters settlement, completed settlement with service balance closeout event 9f805567-b079-484e-ad60-054a53d6a9fd, verified branch settlement dashboard rows and board line items, and reaped the stage batch with SpiceDB cleanup verification.

PAY-004 hosted Kill Bill refund callback reversal proof on 2026-07-12: pnpm supabase:smoke:stage:killbill-refund-callback-to-settlement-reversal seeded paid customer-share balance payment stage-killbill-refund-payment-20260712132758-6e829503 and refund intent stage-killbill-refund-intent-20260712132758-6e829503, posted an official-shape Kill Bill PAYMENT_SUCCESS / REFUND callback, verified inbox event killbill-event:sha256:d0eae42c9d148f6d292ef50de640cb71f631bea830fb7a961271ac823adfed2b, verified duplicate replay did not requeue, dispatched queue message 10, recorded provider refund result killbill:PAYMENT_SUCCESS:stage-killbill-refund-payment-20260712132758-6e829503:stage-killbill-refund-tx-20260712132758-6e829503, mutated the paid row to partial_refunded, persisted settlement reversal, requested all six reporting refresh targets, and reaped stage-killbill-refund-callback-20260712132758-6e829503. Remaining PAY-004 proof is live Kill Bill-originated delivery through the restricted Traefik admission route.

PAY-004 multi-refund callback correlation follow-up on 2026-07-12: backend ProviderRefundResultFromLedgerHandler now resolves provider refund results by explicit refund intent or provider-enriched correlation key matching the ledger refund intent/idempotency key. Kill Bill refund callback ingestion passes this key when present in provider-enriched payload fields. If a payment has multiple refund intents and the callback lacks a correlation key, backend records a repairable failure instead of choosing by amount or row order. Follow-up callback enrichment now adds a provider-neutral ProviderRefundCorrelationLookup application port and wires the Kill Bill HTTP adapter to recover the refund correlation key from /payments/{paymentId} by matching the callback paymentTransactionId to a REFUND transaction and reading its transactionExternalKey. Focused tests cover callback fallback, adapter extraction, and non-refund transaction rejection. Remaining proof is live Kill Bill-originated delivery through the restricted Traefik admission route with real provider transaction lookup.

PAY-004 hosted customer receipt stage proof on 2026-07-12: pnpm supabase:smoke:stage:customer-receipt-tax-evidence-route created booking ba16063f-0b9c-4357-9fc4-b21a91399872, seeded payment stage-customer-receipt-payment-20260712123232-51185685, called the hosted customer receipt route as the mother actor, verified backend-selected reversal artifact customer_receipt_tax_evidence:stage-customer-receipt-payment-20260712123232-51185685:ledger-4:stage-cash-receipt-reversal-20260712123232-51185685, verified provider references stay hidden, and reaped stage-reservation-booking:ba16063f-0b9c-4357-9fc4-b21a91399872 with SpiceDB cleanup verification. Remaining PAY-004 proof is live Kill Bill-originated callback and live provider-originated reversal.

PAY-004 legacy mining follow-up on 2026-07-12 found three still-open source features not covered by cash-receipt gateway evidence alone: VoucherSelfPayReceiptArtifact for admin document id 7 / type7.xlsx voucher self-pay receipts, BranchSettlementRemittanceExport with method-specific fee rules from type18.xlsx, and SettlementArtifactCollection for branch/HQ board-scoped settlement data-room downloads. Evidence: source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:1057, source-refs/sanmopia-admin/application/models/Spreadsheet_model.php:3741, and source-refs/sanmopia-admin/application/controllers/DataRoom.php:86. | SFC-20260710-PAY-005 | P0 | Backend / pricing_settlement | Admin gift-coupon deletion assigns the structured provider refund response directly to a boolean variable, then marks payment refunded and deletes the coupon regardless of nested status at source-refs/sanmopia-admin/application/models/Coupon_model.php:164-207. The provider wrapper proves the response is always a non-empty array whose actual terminal result is status at source-refs/sanmopia-admin/application/libraries/Kcppayment.php:31-59. | GiftCouponRefundSaga, ProviderRefundResultTerminalDecision, GiftCouponRefundRepairCase | RecordGiftCouponProviderRefundResultCommand, CompleteGiftCouponEntitlementCancellationCommand | Existing gift-coupon refund policy/contract foundation is partial; this adapter result gate and repair path are not runtime-proven. | Typed provider result must carry attempt id, provider result code/reference, accepted/rejected/unknown outcome, expected payment/entitlement revisions, and idempotency key. | Missing provider-rejected and provider-unknown tests proving refund flag and entitlement remain unchanged, plus retry/reconciliation proof. | foundation | Never coerce provider response containers to success. Persist attempt/result first; only terminal provider success may transition payment refund state and release the entitlement-cancellation barrier. Rejected or unknown outcomes keep coupon/payment facts intact, block settlement completion, and open a retryable repair case. | | SFC-20260710-PAY-006 | P0 | Backend / pricing_settlement and operator_access | Customer payment paths call inline compensation after local failure and discard its result at source-refs/sanmopia_web/application/controllers/api/Payment.php:164-180 and source-refs/sanmopia_web/application/controllers/api/Payment.php:215-218. Empty provider-module output is collapsed to generic code 9502 at source-refs/sanmopia_web/application/libraries/Kcppay.php:194-203, while automatic cancel always returns a local status => false envelope even though its provider result code may represent success at source-refs/sanmopia_web/application/libraries/Kcppayment.php:418-437. The only legacy repair surface accepts raw provider ids and dumps one response at source-refs/sanmopia-admin/application/controllers/cli/Kcp.php:12-24. | PaymentProviderOperationReconciliation, PaymentProviderAttempt, PaymentOperationRepairProjection, PaymentProviderOperationReconciliationPolicy | ReconcilePaymentProviderOperationCommand, RetryPaymentCloseoutCommand, RetryCompensationRefundCommand | Provider attempts now preserve provider_unknown; append-only reconciliation facts freeze provider evidence, payment/refund ledger revisions, retry time, settlement block, and safe next action. DB constraints prohibit unknown-result retry and permit retry only after provider not_found. Compensation intents and repair execution remain separate existing slices. | Repair query exposes provider/local states, payment and refund ledger revisions, attempt lineage, outcome certainty, retry eligibility/time, settlement block, and allowed actions. Commands require SpiceDB grant, expected revisions, reason, and idempotency. | Stage transaction proved unknown attempt plus reconciliation persistence with await_provider_certainty and settlement blocking, then rolled back all smoke data. Missing public operator query/command, repeated reconciliation history, SpiceDB runtime gate, and live Kill Bill lookup-before-retry E2E. | runtime_wired | Persist accepted, rejected, not_found, or unknown separately for every charge/refund operation. Unknown always blocks settlement and awaits certainty. Only confirmed not_found permits provider retry. Accepted provider work with missing local fact resumes local closeout; matching terminal facts record no-op reconciliation without editing ledger amounts. |

PAY-006 follow-up on 2026-07-12: backend public query GET /reservation-bookings/{reservationBookingId}/payment-provider-operation-reconciliations returns newest-first immutable reconciliation history. Supabase Auth supplies actor identity and SpiceDB close_reservation_finance is the sole access decision; application tests prove denial occurs before Supabase read. Contract schema exposes outcome certainty, revisions, settlement block, retry time, and safe next action without editable amounts. Code composition, HTTP behavior, Tach, and contract gates pass. Stage route E2E remains deployment-pending, so this evidence does not promote PAY-006 to e2e_proven.

PAY-006 command follow-up on 2026-07-12: public reconciliation mutation no longer accepts provider outcome, provider/payment/booking context, operation kind, request key, local-write state, or evidence from browser/operator input. Backend resolves those facts from the provider attempt and ledgers, binds the attempt to the SpiceDB-authorized booking, performs an audited Kill Bill lookup, and maps official transaction type/status into the generic outcome. Exact replay returns the existing fact without a second provider call. Supabase RPC locks the attempt, payment record, and refund ledger rows and enforces payment/refund revision CAS before append. Stage migration, schema lint, type generation, and rollback-safe atomic RPC smoke pass. Live deployed HTTP-to-Kill-Bill proof remains pending; PAY-006 stays runtime_wired rather than e2e_proven.

2026-07-11 family authority, payment, and privacy delta

These rows are new authority boundaries, not duplicates of generic family membership or payer-recipient rows. Detailed evidence and completion gates live in Family Authority, Payment, And Privacy Gap Mining.

feature_id	priority	lane_owner	source_evidence	ddd_aggregate	command_query	persistence	contract	e2e_proof	status	backend_owned_design
`SFC-20260711-FAM-001`	P0	Backend / `member_management` and `reservation_operations`	Mother-only contracting and authenticated-profile booking at `source-refs/sanmopia_web/application/views/service/step1.php:74-93`, `source-refs/sanmopia_web/application/views/service/step1.php:193-209`, and `source-refs/sanmopia_web/application/controllers/api/Service.php:18-59`; spouse is emergency contact, not sponsor authority.	`FamilySponsorshipGrantorPolicy`, `FamilySponsoredReservationDraft`, `SponsoredReservationContractAcceptance`	Grant/revoke sponsorship, submit draft, accept/decline contract, consume acceptance, and acceptance query CQRS	Backend `109a717` persists revisioned grants, drafts, immutable acceptances, one-time consumptions, idempotency, RLS, and SpiceDB relationship outbox work through Supabase transaction functions. Backend `48abf1c` separates request correlation from booking UUID evidence and preserves terminal workflow rows on exact Restate replay; backend `ddd1559` reuses the settlement orchestrator and verifies symmetric DB/SpiceDB cleanup. Backend `5414fa4` adds optimistic contract-catalog rollover plus complete negative-request reaper registration. Stage schema is applied through backend `b0bbd21`.	Contract `15b0261` publishes all six family-sponsorship routes, shared reservation-intent schemas, generated TypeScript types/validators, and optional booking-start acceptance id. Backend derives grantor, sponsor, mother, contract version, request fingerprint, grant/draft revisions, acceptance time, branch operator, address reference, and price reference; browser submits intent only.	The latest continuous stage run created replacement grant `55784662-1e77-4ceb-92b6-4d56511c2a59`, booking `3130d737-d45f-41ef-a4c6-d85cdcd42783`, payer snapshot `73f321bf-7914-5cab-9a2e-aba9640c3771`, and closeout event `bd63b47d-f2a2-49dd-9a79-e5ae6809fdc7`. It passed grant and draft replay, changed-payload rejection, mother accept/query/decline, stale draft rejection, cross-intent reuse denial, revoked-and-replaced grant acceptance rejection, previous contract-version acceptance rejection, one-time consumption, exact booking replay, delegated payment, service delivery, settlement, SpiceDB permission removal, and DB reaping.	`runtime_wired`	Booking creation preserves sponsor actor and consumed grant revision while requiring explicit mother contract acceptance before financially binding progression.
`SFC-20260711-FAM-002`	P0	Backend / `member_management`, `reservation_operations`, and `pricing_settlement`	Distinct legacy deposit, balance, pre-reservation, and payment-change routes at `source-refs/sanmopia_web/application/controllers/api/Payment.php:89-113`, `source-refs/sanmopia_web/application/controllers/api/Payment.php:325-372`, `source-refs/sanmopia_web/application/controllers/api/Payment.php:523-545`, and `source-refs/sanmopia_web/application/controllers/api/Payment.php:681-709`.	`PaymentDelegation`, `ReservationPaymentActorAuthorityDecision`, `ReservationPaymentActorSnapshot`	`GrantReservationPaymentDelegationCommand`, `PreRegisterReservationPaymentCommand`, `GetReservationPaymentPreRegistrationQuery`	Backend `c5c69c8` adds a positive delegation amount ceiling, exact reservation and deposit/balance scope, effective interval, consumed revision, and evidence. Supabase persists the waiting obligation and atomically freezes the authorized actor; SpiceDB remains the coarse `pay_pre_reservation` capability while domain and DB policy enforce the exact payment obligation.	Public pre-registration accepts only `paymentId`, Supabase bearer identity, and `Idempotency-Key`. Method, purpose, product plan, amount, actor kind, delegation revision, and capability decision are backend-owned.	2026-07-11 stage E2E denied caregiver payment, converged the family payer grant, enforced the exact amount ceiling, pre-registered the customer-share deposit, replayed the same command, and rejected a changed idempotency key. Remaining proof: balance, pre-reservation conversion, change-adjustment, expired/under-limit negative HTTP cases, and provider-live E2E.	`runtime_wired`	One broad SpiceDB relationship never decides product or amount. It admits the command; backend aggregate and Supabase RPC must match booking, purpose-derived scope, revision, interval, and ceiling before Kill Bill receives the backend amount.
`SFC-20260711-FAM-003`	P0	Backend / `pricing_settlement` and `customer_engagement`	Legacy checks owner then notifies mother at `source-refs/sanmopia_web/application/controllers/api/Payment.php:95-113` and `source-refs/sanmopia_web/application/controllers/api/Payment.php:182-193`; modern recipient code currently scans grants active at later event time.	`ReservationPaymentActorSnapshot`, `PaymentDelegation`, `PaymentCompletionRecipientDecision`	`PreRegisterReservationPaymentCommand`, `GetPaymentCompletionRecipientDecisionQuery`	Backend `c5c69c8` persists a service-role-only immutable actor snapshot containing actor/mother ids, actor kind, branch, family account, delegation id/revision/scope/ceiling, payment purpose/product/amount, evidence, idempotency, and authorization time. DB triggers reject update/delete except registered stage reaping; mutable payment and delegation rows do not reverse-own the snapshot through FKs.	Handoff response exposes the frozen actor projection but accepts no actor fields. Historical payment facts link the snapshot id; later grant lookup is not payer identity authority.	Stage reservation `92961f7e-7896-4441-af53-8fb8825d6fe2` froze actor snapshot `da2c3402-0d85-52a2-b6b4-bcf7f6c189bf`, then revoked and reaped the grant while proving snapshot retention. Remaining proof: delegate replacement, payment-completion recipient routing, historical receipt/refund visibility, and provider callback consumption.	`runtime_wired`	Grant proves authority at handoff. The immutable snapshot proves historical payer identity and amount after current family grants change. Every completion, receipt, refund, and notification query must consume it.
`SFC-20260711-FAM-004`	P0	Backend / `pricing_settlement` and `operator_access`	Owner-only legacy detail/receipt access at `source-refs/sanmopia_web/application/controllers/MyReservation.php:117-175`, `source-refs/sanmopia_web/application/controllers/MyReservation.php:329-349`, and `source-refs/sanmopia_web/application/views/mypage/reservation_receipt.php:121-127`.	`PaymentParticipantVisibilityPolicy`, `RefundStatusVisibilityProjection`, `PaymentDelegation`	`GrantReservationPaymentDelegationCommand`, `RevokeReservationPaymentDelegationCommand`, `GetPaymentParticipantFinancialStatusQuery`	Booking `authorized_payer` plus distinct `view_payment`, `view_refund`, and `view_receipt` permissions are bound to revisioned reservation-scoped delegation rows. Service-role Supabase RPCs atomically persist grant/revoke and enqueue PGMQ `touch`/`delete`; the shared worker converges expiring SpiceDB relationships. Payment pre-registration now consumes that relationship and freezes exact grant use into the actor snapshot.	Care visibility does not imply finance visibility. Mother, authorized payer, branch finance, and HQ finance use explicit financial permissions; caregiver assignment remains insufficient.	217 changed-slice tests, Tach dependency/interface/external gates, Supabase DB lint with zero errors, authenticated grant/replay/revoke/reaper proof, and the full booking-to-settlement stage chain pass. Remaining proof: inventory and authenticate every payment/refund/receipt read projection.	`runtime_wired`	Persisted family payer capability now reaches a real payment instruction and survives later revocation as frozen evidence. Remaining financial reads must use explicit participant visibility rather than booking `view` or family membership.
`SFC-20260711-FAM-005`	P0	Backend / `member_management` and `care_delivery`	Reservation-specific ownership checks at `source-refs/sanmopia_web/application/controllers/MyReservation.php:213-222`, caregiver report ownership/content at `source-refs/sanmopia-manager/application/controllers/Report.php:21-74` and `source-refs/sanmopia-manager/application/models/Report_model.php:44-67`.	`ReservationCareHistoryAccessGrant`, `ReservationCareHistoryContentAuthorityDecision`, `CustomerDailyReportReviewAuthority`	Grant/revoke/access CQRS plus `GetReservationCareHistoryQuery`; review mutation remains separate	Backend `903e68d` persists revisioned access and SpiceDB outbox. Backend `a88326b` adds shared scope, mother/delegate content authority, strict Pydantic projection, service-role Supabase keyset RPC, backend option-label/note projection, opaque cursor, non-enumerating HTTP boundary, and composition. Corrective stage migration normalizes RPC record contract while retaining strict CMS metadata parsing.	Contract `e4cc9ed` publishes grant lifecycle. Contract `0d576f2` publishes `GET /family-accounts/{familyAccountId}/reservations/{reservationBookingId}/care-history`, OpenAPI, JSON Schema, TypeScript projection types, path builder, and bounded query validator. Public content contains no mother/grant authority metadata.	Stage booking `9c3b61e4-e81e-424d-8d0e-a73b7f53775a`, grant `e3c7ef7a-51c5-47e4-90e3-9486e8915c21`: service-role projection, mother/delegate read, field order, choice label, note, forged review denial, revoke, post-revoke `404`, DB/SpiceDB reaper. Backend focused tests, Ruff, Tach, Supabase lint; contract 396 tests.	`e2e_proven`	Family read never grants review/rating mutation. Backend owns actor resolution, report interpretation, ordering, summary, and pagination. Frontend renders projection only. See ADR-024.
`SFC-20260711-FAM-006`	P0	Backend / `member_management` and platform authorization	Current grant policy treated any non-null revocation as inactive even when evaluating earlier time; no operational revoke command or relationship-delete outbox existed.	`FamilyAuthorityEffectiveInterval`, `PaymentDelegation`	`RevokeReservationPaymentDelegationCommand`, `GetFamilyAuthorityAsOfQuery`	The shared effective interval remains domain authority. Reservation payment delegation now persists revision, actor, reason, evidence, idempotency keys, and timestamps through an atomic Supabase RPC and emits a PGMQ SpiceDB relationship delete. Exact replay ignores backend-generated clock drift but rejects changed actor, reason, or expected revision. Sponsorship and care-history still need equivalent persisted lifecycle wiring and a general as-of query.	Historical use remains valid only when `granted_at <= used_at < revoked_at`; current access stops at revocation.	Colocated tests plus authenticated stage HTTP E2E prove operational revoke, exact replay, queue dispatch, SpiceDB permission removal, and test-data cleanup. SQL smoke proves revision 2 and one delete message inside a rollback transaction.	`runtime_wired`	Reservation payment authority no longer requires hard delete or manual SpiceDB cleanup. Remaining work generalizes persisted as-of reads and lifecycle outbox handling to sponsor and care-history grants.
`SFC-20260711-FAM-007`	P1	Backend / `member_management` and platform access	Owner-only legacy reservation lists at `source-refs/sanmopia_web/application/controllers/MyReservation.php:22-48` and `source-refs/sanmopia_web/application/controllers/MyReservation.php:73-98`; current family-account RLS exposes authority metadata to any linked family member.	`FamilyAuthorityGrantDirectoryVisibilityPolicy`, `FamilyAuthorityDirectoryView`	`GetFamilyAuthorityDirectoryQuery`, `GetFamilyAuthorityAdministrationProjection`	Backend `bb4d6ee` adds a Pydantic authority-directory projection and HTTP read boundary. `own` view returns only the actor’s sponsorship, payment-delegation, and care-history grants; `administration` view requires mother domain authority plus SpiceDB `administer` on the family account. Backend `4477372` drops authenticated raw table read policies and revokes direct authenticated `select` on family authority grant tables so Supabase RLS cannot become a competing directory. Backend `13dc531` adds inactive-actor proof for withdrawn Supabase sessions and revoked family members. Backend `dde8177` adds stage HTTP proof to the care-history access smoke.	HTTP response excludes authority evidence and does not let browser choose actor/member ids. Subject sees own effective grants; mother administrator sees managed family authority projection through backend permission. Service-role backend remains the raw grant reader.	Focused API/HTTP tests prove own-view filtering, admin SpiceDB denial, non-mother admin rejection, hidden authority evidence, withdrawn-member denial, and revoked-family-member denial. Lexical migration tests prove legacy policies are dropped, authenticated raw reads are revoked, service-role reads remain, and table comments point readers to backend API. Stage booking `f175bd00-441f-4801-b21d-3081bfa75682`, grant `aecf7aa6-d034-407d-9148-74deb5f87d1c`: active delegate `own` directory visibility, hidden evidence, non-admin `administration` denial, revoke, post-revoke disappearance, SpiceDB cleanup, and registered test-data reap.	`e2e_proven`	Family membership is not authority-directory administration. Backend query permission now owns directory visibility; raw Supabase grant rows are not browser-facing authority directory surfaces.

Source Feature Checklist

Source Feature Checklist

Delegation Control Notes

Newly Confirmed Unclosed Gaps

2026-07-05 Persistent Worker Legacy Mining Delta

2026-07-05 Payment/Refund Source Pass

2026-07-05 Legacy Feature Curator Pass

2026-07-05 Static JS/Admin View Curator Pass

2026-07-05 Coupon/Settlement Detail Addendum

2026-07-05 Data-Room/Document Export Addendum

2026-07-05 CaveCrew Explorer A Hidden Feature Delta

Legacy UI/PHP Calculation Migration Rule

CaveCrew Source Gap Queue

Current Closeout Flow Marker

CaveCrew Reconciliation Delta 2026-07-05

CaveCrew Source Gap Delta 2026-07-05

Open Gap Register

2026-07-06 Source-Dig Delta

Lane C Source Feature Checklist Gaps

Actor Feature Checklist

HeadOfficeManager

BranchOwner

Mother/FamilySponsor

CareManager

Source Coverage

Runtime Test Data Hygiene

2026-07-03 Source Survey Delta

2026-07-05 Acceptance Vocabulary Delta

2026-07-05 CaveCrew Migration Refresh

2026-07-03 Admin UI Decision Delta

2026-07-03 Notification And Document Delivery Delta

2026-07-03 Sidecar Feature Gap Delta

2026-07-03 Additional Hotspot Queue

Mother And Public Web

Admin And Branch Backoffice

Caregiver Manager App

Native Shell And Platform

Modern Replacement Tracking

2026-07-06 Planck Backend Rule Mining

2026-07-06 Frontend Lane Hidden PHP/UI Delta

2026-07-08 Frontend Reservation UX Evidence

2026-07-06 Feature Checklist Curator Addendum

2026-07-06 Backend Migration Follow-Up

2026-07-09 persistent legacy-gap mining refresh

2026-07-09 persistent legacy-mining status refresh

2026-07-10 Branch/Admin Analytics Workflow Refinement

2026-07-10 Settlement/Data-Room Operator Workflow Refinement

2026-07-10 Reservation-To-Settlement Source Authority Consolidation

2026-07-10 persistent legacy payment miner delta

2026-07-11 family authority, payment, and privacy delta