Leyve Docs

다크모드

호스피탈리티 룸 마스터 백엔드 계약 ​

As-built ​

정본 migration은 20260718160000_hospitality_room_master_crud.sql이다. 기존 hospitality_rooms와 property_spaces를 그대로 사용하며 별도 물리 공간 root를 만들지 않는다.

  • 시스템 UUID는 내부 FK이며 고객에게 노출하지 않는다.
  • management_code는 비워두면 자동 생성하고 생성 요청에서만 사용자가 지정할 수 있다.
  • 고객 노출 식별자는 기존 legacy_room_id 컬럼에 보존되지만 API에서는 registration_code로만 노출한다. 생성 후 변경할 수 없다.
  • property_space_id는 Company·Office가 같은 활성 guest_room|meeting_room|desk에만 연결하고 생성 후 변경할 수 없다.
  • 수정 가능 필드는 display_name, room_type_code, inventory_status뿐이다. W18부터 room_type_code를 바꿀 때 같은 Office의 active hospitality_room_types만 허용한다.
  • 삭제 RPC는 없다. 재고 제외는 inactive|maintenance, 복귀는 active로 표현한다.

RPC ​

  • list_hospitality_room_master_v1(company, office): 룸과 연결 가능한 프로퍼티 공간을 반환한다.
  • create_hospitality_room_master_v1(...): 공간·등록코드·관리코드를 고정하고 룸을 생성한다. 기존 Wave 15 trigger가 운영 상태를 inspected로 초기화한다.
  • update_hospitality_room_master_v1(...): expected master revision을 검사하고 세 가변 필드만 갱신한다.

모든 public 함수는 security invoker이고, 호출 가능한 private 구현에만 authenticated execute를 부여한다. 구현은 auth.uid(), Hospitality entitlement, Company·Office read/manage 권한을 다시 검사한다. 같은 command request key와 같은 payload는 저장된 응답을 반환하고, 다른 payload 재사용은 거부한다.

상태·원장 불변식 ​

hospitality_room_master_events는 create/update 전후 payload와 revision을 보존하는 append-only 감사 원장이다. private.hospitality_room_master_commands는 멱등 응답 원장이며 두 원장 모두 UPDATE/DELETE trigger가 변조를 거부한다.

룸을 active에서 inactive|maintenance로 바꿀 때 같은 룸에 held|confirmed|checked_in allocation 또는 checked_in stay가 있으면 hospitality_room_master_inventory_in_use로 거부한다. 이름·룸 타입 수정은 예약·점유·folio·하우스키핑 원장을 바꾸지 않는다. 마스터 revision과 하우스키핑 revision은 서로 독립이다.

룸 생성은 선택한 공간에 immutable hospitality_room_id alias를 같은 트랜잭션에서 연결한다. 등록코드가 다른 공간의 alias로 이미 사용 중이거나 공간이 다른 룸에 연결되어 있으면 거부한다.

20260718180000_hospitality_room_type_master.sql은 hospitality_rooms(company_id, office_id, room_type_code)에 same-scope FK를 NOT VALID로 추가한다. 이 상태에서도 신규·변경 FK는 강제되며 기존 opaque code만 유지된다. 신규 룸 배정은 active 타입이어야 하고 room_type.space_category = property_space.space_type도 만족해야 한다. 기존 룸이 가리키는 타입이 나중에 inactive가 되어도 같은 코드를 유지한 이름 변경은 허용한다.

제품 경계 ​

이 계약은 Hospitality entitlement만 요구한다. 시설관리·회계·전자결재 상품을 호출하지 않는다. 프로퍼티 공간은 플랫폼 코어 identity로만 사용한다. 턴다운·DND·MUR, 연결룸·컴포넌트 스위트, 부속 마스터와 일괄 업로드는 후속 범위다.

검증 ​

  • 실제 PostgreSQL rollback: supabase/tests/hospitality_room_master_smoke.sql
  • migration 계약: hospitalityRoomMasterMigration.spec.js
  • repo payload: hospitalityRoomMasterRepo.spec.js
  • UI 계약: hospitalityRoomMasterUi.spec.js

smoke는 인증 관리자 public RPC 성공, 무권한 사용자 차단, create/update 재시도, revision 충돌, 공간·코드 불변, 예약 중 비활성화 거부, 운영 상태 초기화, 감사·운영 원장 분리를 검증한다.