0033. Physical room blocks and maintenance

• Status: Proposed
• Date: 2026-10-27

Observable acceptance criteria

Admin and front desk can create, edit, end early and remove a future dated unit block. Housekeeping can create and manage OOS blocks. Every workspace role can read blocks and maintenance tickets. An OOO block decreases room-type availability for each occupied property-local night, enqueues availability ARI rows, and can show negative availability without changing sold bookings. An OOS block leaves sellable availability alone but prevents new physical assignments and check-in while active. An assigned stay cannot be covered by a newly created or enlarged block. Block changes and ticket changes survive reload; invalid or denied changes leave the previous record intact. Closing a ticket never changes housekeeping or a block.

Decision

Blocks use half-open civil date ranges. Two active blocks cannot overlap on the same unit, regardless of kind. This prevents double inventory deductions and makes the physical state unambiguous. A property write gate serializes block changes with reservations and room configuration. The inventory ledger has an independent nonnegative out_of_order count; availability is active units minus sold minus out_of_order. An OOO can overbook already sold stays on other units. It is rejected only when a current physical assignment on its own unit overlaps. The available count is permitted to be negative and the API exposes it.

An edit applies only the difference between the old and new OOO night sets. ARI rows cover the affected old and new ranges in the same transaction. Future deletion is limited to blocks whose start is after the property’s local today. Ending early replaces the end date with today or a later date inside the original range; the range always remains nonempty. Notes and reasons are tenant data, absent from audit and event payloads.

Maintenance tickets are independent records linked optionally to a block. Their open/done state does not change housekeeping or inventory. A ticket may remain after a future block is deleted, with its link cleared. No automated maintenance scheduling or photos are included.

The planning grid keeps its existing stay contract and adds separate physical block bars and a separate range action. The UI never treats a selected free physical range as proof of sellable capacity. The server is authoritative for assignment, OOO overlap and ARI effects.

API revision 1.10.0 requires a strong If-Match ETag on block edits, early end, future deletion and ticket edits. Successful writes return the new ETag. Missing or weak preconditions are rejected before domain mutation.