## ADDED Requirements

### Requirement: Adapter workflow state is durable and queryable
The RB-owned adapter SHALL durably track each occurrence workflow across the atomic RB booking/reservation/audit/command-outbox transaction, dedicated Kafka command publish, TT command/receipt, TT Phase 1 Kafka acknowledgement, and reservation confirmation/release. Timetabler and the RB-owned authority SHALL expose bounded authenticated idempotent status lookup by stable identity so timeouts or Kafka delay are not treated as proof of failure.

#### Scenario: TT command times out after commit
- **WHEN** the adapter does not receive the command response but Timetabler committed the mapping/activity/outbox
- **THEN** retry or status lookup returns the existing versioned result and the adapter confirms the reservation without creating/deleting another booking

#### Scenario: TT command times out before commit
- **WHEN** status lookup proves there is no applicable receipt/commit
- **THEN** the adapter may retry with the same idempotency key or release/expire the hold according to workflow policy

### Requirement: Compensation never uses blind deletion
On timeout, retry exhaustion, crash, or contradictory observations, the adapter SHALL query Timetabler receipt, authority reservation, and Resource Booking transaction state before compensation. It SHALL NOT blindly delete a booking based only on a missing response.

#### Scenario: RB outcome is ambiguous
- **WHEN** the adapter loses the RB commit/confirm response
- **THEN** it queries RB and authority by stable transaction/reservation identity before changing TT or releasing protection

#### Scenario: Confirmation is delayed
- **WHEN** TT is committed and authority confirmation remains pending beyond its service objective
- **THEN** the ledger continues blocking conflicts, durable retries/alerts run, and TT state is not blindly rolled back

### Requirement: Update and cancellation races are serialized
The mapping/receipt version and reservation fencing token SHALL serialize concurrent create/update/cancel work for the same occurrence. Older commands or tokens SHALL NOT overwrite, confirm, release, or delete a newer state.

#### Scenario: Update races with cancellation
- **WHEN** a later cancellation and an earlier update execute concurrently
- **THEN** monotonic version and fencing rules produce one deterministic final state and the stale operation cannot mutate or release the winner's scope

#### Scenario: Repeated cancellation after newer reactivation
- **WHEN** an old cancellation is redelivered after an explicitly allowed higher-version reactivation
- **THEN** the old cancellation is rejected as stale and the current booking remains protected

### Requirement: Echo acknowledgement cannot form a loop
The adapter SHALL recognize TT outbound events caused by an RB occurrence command using origin, source/occurrence/version, correlation/causation, receipt, and reservation identity. Matching events SHALL advance acknowledgement state but SHALL NOT generate a new RB booking mutation or another TT command.

#### Scenario: Matching echo is redelivered
- **WHEN** the same TT acknowledgement event is delivered repeatedly
- **THEN** adapter inbox idempotency leaves workflow/RB state unchanged after the first application and no loop occurs

#### Scenario: TT-originated edit affects an RB-mapped occurrence
- **WHEN** Timetabler legitimately changes a mapped occurrence with a non-RB origin and valid reservation
- **THEN** the adapter treats it as a new authoritative TT change, applies the versioned RB update, and correlates any resulting acknowledgement without looping

### Requirement: Reconciliation repairs cross-system workflow state
Scheduled reconciliation SHALL compare source mappings/versions, native TT booking state, TT outbox/acknowledgements, authority ledger state, and RB booking state to detect missing, stale, orphaned, ambiguous, or stuck workflows. It SHALL be a repair mechanism, not the primary transaction path.

#### Scenario: Mapping exists but TT activity is missing
- **WHEN** reconciliation finds a current RB mapping/ledger record without its expected native TT activity
- **THEN** it reports the invariant breach and performs an approved idempotent replay/repair while keeping conflict protection active

#### Scenario: Ledger has an orphaned hold
- **WHEN** a reservation is expired/stuck with no committed TT/RB state after status checks
- **THEN** reconciliation releases/expires it with audit evidence and does not alter unrelated bookings

#### Scenario: RB and TT versions differ
- **WHEN** the systems disagree on the current occurrence version
- **THEN** source ownership/version rules select the authoritative latest valid state and targeted idempotent repair converges them

### Requirement: Operations expose conflicts, fencing, and ambiguity
Structured metrics/logs/traces/dashboards/alerts SHALL cover ingress outcome/latency, duplicate/stale/hash mismatch, reservation state and TTL margin, conflicts, fail-closed rejects, fencing errors, pending confirmation age, echo suppression, ambiguous workflows, and reconciliation divergence using stable correlation identifiers.

#### Scenario: Confirmation age breaches objective
- **WHEN** a committed TT booking remains pending authority confirmation beyond the configured threshold
- **THEN** an alert identifies tenant, occurrence/mapping, reservation/change-set correlation, protected scope, retry state, and runbook without leaking credentials

#### Scenario: Conflict rate spikes
- **WHEN** reservation rejections exceed the baseline/threshold
- **THEN** operators can distinguish legitimate contention, stale mapping/feed, clock/timezone errors, and authority faults from metrics and safe conflict evidence

### Requirement: Cutover starts from a paused reconciled baseline
Before enabling bidirectional shared writes, operators SHALL pause shared-resource writes as needed, reconcile Timetabler and Resource Booking, seed source mappings and an authority ledger for all confirmed allocations, resolve every conflict/mapping/timezone error, verify zero conflicts and agreed divergence, then enable enforcement on both systems before lifting Phase 1 mirror-only restrictions.

#### Scenario: Existing conflict is found during seeding
- **WHEN** the baseline contains overlapping TT/RB allocations
- **THEN** cutover remains blocked until owners resolve the conflict and reseeding/reconciliation reports zero conflicts

#### Scenario: Only one system has enforcement enabled
- **WHEN** coordinated enablement cannot be proven on both Timetabler and Resource Booking
- **THEN** shared writes remain paused/mirror-only and bidirectional cutover does not proceed

#### Scenario: Cutover succeeds
- **WHEN** mappings/ledger are seeded, zero conflicts are verified, both gates are active, and end-to-end create/update/cancel acknowledgement tests pass
- **THEN** Phase 1 mirror-only resources may be changed to bidirectional and writes resume gradually under monitoring

### Requirement: Rollback never returns to uncoordinated writes
After Phase 2 enforcement is active, rollback SHALL pause shared writes, stop new RB-to-TT ingress, retain authority enforcement for existing scopes, drain/reconcile in-flight workflows, and either resume Phase 2 or deliberately restore Phase 1 mirror-only ownership before writes resume. Disabling the authority while both systems can write SHALL be prohibited.

#### Scenario: Authority deployment must be rolled back
- **WHEN** the authority or adapter version is unsafe
- **THEN** shared writes are paused and existing ledger protection remains until a compatible version or controlled Phase 1 mode is established

#### Scenario: Timetabler ingress is disabled
- **WHEN** RB-to-TT command ingress is feature-disabled during rollback
- **THEN** RB shared writes also pause or revert to mirror-only restrictions so no unmirrored conflicting confirmation can occur

### Requirement: Race, crash, timezone, and load acceptance is cross-service
Phase 2 production enablement SHALL require passing TT-vs-RB, TT-vs-TT, RB-vs-RB, bulk all-or-none, stale fencing, timeout/retry, crash-at-each-transition, echo, recurrence/timezone/DST, authentication/tenant, reconciliation, load, TTL, clock-skew, and rollback tests for Timetabler, adapter, authority, and Resource Booking.

#### Scenario: Any required race test produces conflict
- **WHEN** a required acceptance run yields overlapping confirmed allocations or a confirmed allocation without ledger evidence
- **THEN** cutover is blocked regardless of eventual reconciliation outcome

#### Scenario: Load causes TTL safety-margin breach
- **WHEN** production-like load causes reserve-to-local-commit timing to violate the agreed lease safety margin
- **THEN** enablement is blocked until TTL/renewal/capacity is corrected and the suite passes