호스피탈리티 예약 프론트엔드 유지보수

구성

hospitalityReservationRepo.js
  ├─ hospitality_rooms / hospitality_reservations 조회
  ├─ create/update/hold/confirm/cancel/check-in RPC
  └─ 서버 row → 기존 예약 테이블 view model normalize

useReservations.js
  ├─ Supabase 설정 시 server repo, 미설정·test 시 빈 repo
  ├─ Company·Office scope 변경 시 server 목록 초기화
  └─ reservation/room 목록 및 command 결과 upsert

reservation/MainOrg.vue
  ├─ 목록·룸 초기 load
  ├─ DialogCreateArt: 룸 30분 홀드 예약 생성
  ├─ DynamicTableOrg: held 확정 / confirmed 체크인
  ├─ DialogCheckinArt: reservation check-in 단일 RPC
  └─ DialogNoShowArt: 예약 취소만 수행

check_in_hospitality_reservation이 stay 생성까지 원자적으로 처리하므로 check_in_hospitality_stay를 별도로 호출하지 않는다. UI는 RPC 성공 응답의 reservation을 upsert하고 룸 운영 projection을 다시 읽는다. 로컬 stay·room 샘플 상태를 만드는 fallback은 없다.

loadReservationWorkspace()는 예약과 룸 재고를 한 Office scope에서 병렬 조회한 뒤 두 결과를 함께 반영한다. scope generation과 목록별 sequence가 이전 Office 응답을 폐기한다. 모든 create/update/hold/confirm/cancel/check-in 명령도 시작 Office를 캡처하며, 응답 전에 Office가 바뀌면 결과를 null로 반환하고 새 Office 목록에 upsert하지 않는다. stale 요청의 오류·loading도 현재 Office 상태를 덮지 않는다.

화면 규칙

• 예약 등록은 server room inventory에서 룸을 선택하고 held 상태로 생성한다.
• held에는 예약 확정, confirmed에는 체크인만 노출한다.
• 취소는 draft/held/confirmed에만 노출한다.
• 취소 다이얼로그는 예약·allocation 해제만 약속한다. 위약금·환불·분개 미리보기를 만들지 않는다.
• 서버 오류는 capability, 기간 겹침, revision 충돌을 사용자 문장으로 변환한다.
• 서버 미연결, 초기 로딩, 서버 오류·재시도, Supabase 실제 0건 상태를 구분하고 실제 행이 있을 때만 테이블을 표시한다. 빈 repo는 예약 서버 연결 필요를 표시하며 예약 등록 버튼도 비활성화한다.
• 체크인·취소 버튼은 클릭한 rsv 객체를 그대로 emit해 두 다이얼로그가 같은 선택 행을 소비한다.

룸 보드·하우스키핑은 hospitalityRoomOperationsRepo와 서버 운영 상태를 사용한다. 체크인은 UI의 active + vacant + inspected 후보 필터와 DB readiness gate를 함께 적용한다. 자세한 계약은 hospitality-room-operations.md를 따른다.

MainOrg.vue의 active graph에는 BlockTableOrg, useRoomBlocks, DialogChannelSettlementArt import·mount가 없다. 그룹 객실 블록, 외부 예약 채널 가져오기, 채널 정산·예약명세서는 별도 adapter와 서버 원장이 생기기 전까지 메뉴·버튼·샘플로 노출하지 않는다. 비활성 프로토타입 파일이 남아 있더라도 active 예약 제품 그래프에서 참조하면 안 된다.

테스트

• hospitalityReservationRepo.spec.js: normalize와 RPC payload
• hospitalityReservationMigration.spec.js: 상품 경계, capability, 원자 체크인
• hospitalityReservationUi.spec.js: 생성·확정·체크인·취소 노출 계약
• hospitalityReservationUi.spec.js: active graph의 블록·채널 mock, 하드코딩 PII·금액, 죽은 선택 UI 부재 계약
• useReservationsScope.spec.js: Office 전환 중 stale 목록·오류·명령 성공 폐기 계약
• hospitality_reservation_room_allocation_smoke.sql: 실제 상태머신, 겹침, idempotency, RLS

스테이·folio·체크아웃 (2026-07-18)

useStays.js는 lease 소유 usePropertyOccupancyPeriods를 소비하지 않으며 빈 배열·backend='empty'에서 시작한다. Office scope별로 hospitalityReservationRepo.listStays()와 getFolio()를 호출하고, 저장소는 list_hospitality_stays_v1·get_hospitality_folio_v1 payload를 같은 stay·folio view model로 정규화한다. mock guest·금액·folio와 로컬 체크아웃 fallback은 없다.

scope generation, list/detail sequence, operation sequence가 Office 전환 뒤 도착한 목록·folio 상세·오류·loading·mutation 성공을 폐기한다. 체크아웃 다이얼로그도 선택 stay id와 submit sequence를 캡처하므로 늦은 이전 Office 성공이 현재 다이얼로그를 닫거나 오류를 덮지 않는다. Office 변경 시 목록이 비워지고 새 Office를 자동 조회하며 MainOrg의 선택 행도 목록에서 사라지면 즉시 해제된다.

MainOrg.vue가 초기 load, retry, 선택 행을 소유한다. 상태 우선순위는 loading → error → backend !== 'supabase' → Supabase 실제 0건 → table이다. folio 번호 클릭과 행 체크아웃이 클릭한 객체를 그대로 전달하고, openStay()가 getFolio()로 최신 행을 확인한 뒤에만 sheet/dialog를 연다. 체크박스, 전용 상세 아이콘, 별도 체크인, 야간 마감 버튼은 active graph에 없다.

stay/HeaderOrg.vue는 Hospitality 소유 예약·스테이·룸 상태·하우스키핑만 노출한다. 청구·수납·세금계산서 상품으로 직접 이동하는 탭은 optional adapter 경계를 오해하게 하므로 active stay graph에서 제거했다.

체크아웃 다이얼로그는 expectedStayRevision, expectedFolioRevision, settlementMode, 화면에 받은 expectedSettlementAmount를 confirm_hospitality_checkout_v2에 전달한다. 성공 뒤 같은 captured Office로 listStays()를 재조회하며 scope가 유지될 때만 목록을 교체한다. 룸의 dirty 전환은 checkout transaction 안의 DB trigger가 담당하므로 UI가 useRooms를 호출하거나 로컬 상태를 만들지 않는다.

folio sheet는 서버 entry만 표시하고 0건이면 정직한 empty를 표시한다. checkout 화면에는 가상 분개·수수료 계산이 없다. 채널명은 특정 업체명이 아닌 예약 채널로 표시한다. 실제 결제·회계·청구 adapter는 아직 없고 optional 전달 상태만 표시한다. Hospitality checkout은 이 상품들이 없어도 동작한다.

검증은 hospitalityReservationUi.spec.js, useStaysScope.spec.js, hospitalityReservationRepo.spec.js, hospitalityFinancialLedgerMigration.spec.js, hospitality_financial_ledgers_smoke.sql이 담당한다.