## ADDED Requirements

### Requirement: One RB-owned authority prevents shared conflicts
Before Timetabler or Resource Booking confirms any shared Staff/Location allocation, the RB-owned reservation authority SHALL atomically reserve the complete set of Staff, Locations, occurrences, and time ranges. No confirmed allocation in either system SHALL exist without an authoritative reservation/fencing record covering its full scope.

#### Scenario: TT and RB race for the same Location
- **WHEN** Timetabler and Resource Booking concurrently reserve overlapping time for the same shared Location
- **THEN** exactly one all-or-none reservation succeeds and the rejected caller receives safe evidence of the conflicting booking/reservation

#### Scenario: TT and TT race for shared Staff
- **WHEN** two Timetabler writers concurrently reserve overlapping time for the same shared Staff member
- **THEN** the authority serializes the decision so at most one can commit

#### Scenario: RB and RB race
- **WHEN** two Resource Booking transactions contend for overlapping shared scope
- **THEN** the same authority invariant prevents two confirmed RB bookings

### Requirement: Reservation operations are idempotent and fenced
The RB-owned authority SHALL expose bounded synchronous authenticated reserve, confirm/consume, renew, release, expire, and status operations using deterministic idempotency keys, monotonically fenced tokens/versions, scope hashes, auditable states, TTL/renewal, and clock-skew safety margins. Kafka SHALL NOT be used as the pre-commit mutual-exclusion decision.

#### Scenario: Reserve request is retried
- **WHEN** a caller repeats the same reserve idempotency key and identical scope after a timeout
- **THEN** the authority returns the same reservation/fencing outcome rather than allocating a second hold

#### Scenario: Same key is reused for another scope
- **WHEN** an idempotency key is repeated with a different assignment scope hash
- **THEN** the authority rejects it as a protocol conflict and does not alter either scope

#### Scenario: Stale fencing token confirms
- **WHEN** an expired/replaced reservation's older fencing token attempts confirmation or release
- **THEN** the authority rejects it and leaves the newer protected state unchanged

#### Scenario: Lease approaches expiry
- **WHEN** a valid workflow cannot complete with the agreed safety margin before expiry
- **THEN** it renews through the fenced protocol before local commit or fails/releases without committing shared allocation

#### Scenario: Authority decision is delayed behind asynchronous transport
- **WHEN** a writer cannot obtain a bounded synchronous authoritative reserve/status result before its commit deadline
- **THEN** it fails closed and does not treat queued Kafka delivery or cached advisory availability as conflict permission

### Requirement: Multi-resource and bulk reservations are all-or-none
The authority SHALL check and hold the union of every Staff, Location, occurrence, and time range in one atomic operation. If any member conflicts or fails validation, no subset SHALL be reserved or committed silently.

#### Scenario: One resource in a booking conflicts
- **WHEN** a booking requires two Staff and one Location and one Staff member conflicts
- **THEN** the entire reserve request fails and no hold is retained for the otherwise-free resources

#### Scenario: One engine assignment in a bulk result conflicts
- **WHEN** a bulk final engine result contains multiple successful assignments and any occurrence/resource conflicts
- **THEN** reservation of the entire successful batch fails, Timetabler commits none of those successful assignments, and bounded reschedule/retry or complete rejection is invoked

#### Scenario: Engine result contains no-slot items
- **WHEN** some engine result items have no final `start_slot`
- **THEN** they remain unchanged and are excluded from the reservation scope, while all successful assignments still form one atomic batch

### Requirement: Every Timetabler allocation writer is gated
All authoritative Timetabler shared-resource allocation writers identified in Phase 1 SHALL acquire and validate full-scope reservation evidence before commit, including final engine schedules/swaps, drag/drop final apply, manual constraint-break, booking create/update/schedule/swap/import, unschedule/delete transitions where protocol coordination is required, current-resource and scheduled-requirement replacement, week/date/duration/pattern changes, variants/JTA, imports, simulation/legacy consumers, cascading parent deletes, and management commands. Constraint-breaking modes SHALL NOT bypass this gate; obsolete writers SHALL be provably decommissioned rather than exempted.

#### Scenario: Direct writer lacks reservation evidence
- **WHEN** an admin endpoint, import, command, or consumer attempts a shared-resource allocation without valid reservation scope/fencing
- **THEN** Timetabler fails closed before authoritative commit and emits no success/outbox allocation event

#### Scenario: Manual constraint-break requests a conflict
- **WHEN** manual constraint-break relaxes local scheduling preferences but the authority rejects the shared resources
- **THEN** Timetabler does not commit the allocation

#### Scenario: Scheduled week or duration changes
- **WHEN** a writer changes occurrences by editing week/date/duration/time
- **THEN** it reserves the complete new occurrence scope atomically while protecting the old committed scope until replacement confirms

#### Scenario: Legacy or cascading writer is invoked
- **WHEN** a live legacy/simulation response path or parent/pattern deletion changes or releases shared allocation scope
- **THEN** the same authority transition and TT atomic/outbox guarantees apply, or the path rejects the operation because it has been formally disabled for shared scheduled state

### Requirement: Network acquisition precedes Timetabler locks
Timetabler SHALL construct and reserve a complete proposed change outside `transaction.atomic()`. It SHALL NOT hold Timetabler database locks across adapter/authority network calls. Inside the transaction, immediately before commit, it SHALL validate the reservation protocol version, tenant, full assignment scope hash, fencing token, and sufficient unexpired lease margin using the held reservation evidence.

#### Scenario: Authority times out before transaction
- **WHEN** reservation acquisition times out or authority availability is unknown
- **THEN** Timetabler opens no final-application transaction and fails the shared-resource write closed

#### Scenario: Evidence scope differs from final assignment
- **WHEN** the final locked Timetabler change set does not hash to the reservation's complete scope
- **THEN** Timetabler rolls back/rejects before commit and releases/expires the reservation safely

#### Scenario: Evidence expires while locks are held
- **WHEN** lease margin is insufficient at the final in-transaction validation point
- **THEN** Timetabler aborts the transaction rather than committing under an expired/unsafe hold

### Requirement: Commit is followed by durable reservation confirmation
Timetabler SHALL commit native state, resource maps, receipt, TT outbox, and a durable reservation-confirm intent before invoking authority confirmation. Confirm/consume SHALL be idempotent. If commit fails, the hold SHALL be released/expired; if confirmation delivery fails after commit, the scope SHALL remain authoritative and blocking until durable retry/reconciliation resolves it.

#### Scenario: Timetabler commit fails after reserve
- **WHEN** the local database transaction rolls back
- **THEN** no TT allocation/outbox success exists and the reservation is released or safely expires without a stale confirmation

#### Scenario: Confirm call is lost after TT commit
- **WHEN** TT commits but the post-commit confirm response is lost
- **THEN** durable retry/status reconciliation confirms idempotently and conflicting new reservations remain blocked during ambiguity

#### Scenario: Worker crashes after commit before confirm
- **WHEN** the process crashes after TT commit and before sending confirmation
- **THEN** the durable intent is recovered, no booking is blindly deleted, and the authority scope stays protected

### Requirement: Authority unavailability is fail-closed
Timeout, unavailable authority, invalid/expired reservation, stale fencing, indeterminate scope, or stale occupancy feed SHALL NOT permit a shared-resource allocation commit. Availability degradation SHALL be observable to users/operators and retryable without duplicate allocation.

#### Scenario: Authority is unavailable
- **WHEN** any TT or RB shared-resource writer cannot obtain an authoritative decision
- **THEN** the write is rejected/deferred with a safe retryable outcome and neither system confirms it

#### Scenario: Fail-open flag is requested
- **WHEN** configuration or an operator attempts to bypass enforcement during Phase 2
- **THEN** the system refuses uncoordinated shared writes; rollback requires pausing writes or returning resources to controlled Phase 1 mirror-only mode

### Requirement: Pre-schedule is advisory but final check is mandatory
Pre-schedule candidate generation SHOULD incorporate current RB bookings/reservations for better suggestions, but SHALL remain read-only. Timetabler SHALL perform a new authoritative reservation against the final complete engine assignment immediately before final database commit.

#### Scenario: Availability changes after pre-schedule
- **WHEN** a slot was shown available during pre-schedule but RB reserves it before final apply
- **THEN** final reservation rejects/reschedules the assignment and Timetabler does not commit a conflict

#### Scenario: Pre-schedule feed is stale
- **WHEN** advisory RB occupancy data is stale or unavailable
- **THEN** candidate quality may degrade but no final shared write commits without the live authoritative reservation gate

### Requirement: Time and recurrence comparison is canonical
The authority and adapter SHALL compare occurrence intervals using the agreed UTC instant plus IANA timezone/calendar context and half-open interval semantics. Recurrence expansion, DST transitions, academic-term mapping, and clock skew SHALL have deterministic contract tests.

#### Scenario: DST boundary occurrence
- **WHEN** a local recurring booking crosses a daylight-saving transition
- **THEN** each expanded occurrence reserves the correct UTC interval and conflicts are evaluated against the same instants in both systems

#### Scenario: Adjacent bookings meet at boundary
- **WHEN** one booking ends exactly when another begins
- **THEN** agreed half-open interval semantics classify them consistently without an artificial overlap