# Cross-Repository Phase 2 Traceability

## Pinned planning counterparts

| Service | OpenSpec change | Planning pin | Status |
| --- | --- | --- | --- |
| Timetabler BE | `phase-2-bidirectional-booking-conflict-control` | This change on Timetabler Phase 1 base `b29ee4c21a04f7f4cb7cc7b36faa2484cf294007` | Strict validation required after every alignment update |
| Resource Booking BE | `integrate-resource-booking-to-timetabler-phase-2` | `88c3cd5eaff085c70ab84f4e446b68268c87008b` | 26 requirements, 72 scenarios, 109 tasks; strict validation passed |

The Resource Booking branch name is informational. The immutable commit above is the
reviewed planning input. Changing either pin requires a compatibility review of the
command, authority, echo, recovery, testing, and cutover contracts.

## Shared transaction and transport contract

| Sequence | Resource Booking responsibility | Timetabler responsibility | Safety evidence |
| --- | --- | --- | --- |
| 1. Conflict decision | Use the RB-owned synchronous authenticated authority/status API to reserve complete typed Staff/Location/occurrence/time scope all-or-none with idempotency, scope hash, fencing and TTL | Every TT shared writer calls the same authority outside its DB transaction and fails closed without a bounded valid result | Authority reservation/status record and safe conflict evidence |
| 2. RB commit | Atomically record booking/allocation, authoritative reservation transition, audit/workflow and dedicated command outbox | None | One RB transaction; no partial booking/command intent |
| 3. Command delivery | Publish one typed create/update/cancel Kafka command per expanded occurrence from the dedicated outbox; generic lifecycle events remain a separate role | Consume with `read_committed`, stable occurrence ordering and manual durable-outcome-only offsets | Broker acknowledgement is transport evidence, not TT application evidence |
| 4. TT commit | Await TT receipt/status or echo; do not infer failure from timeout | Atomically apply one native booking activity, mapping/receipt, complete Staff+Location/time/week state, resource maps, audit, ordinary Phase 1 event and durable follow-up intent | One TT transaction and idempotent mapping/version/hash result |
| 5. Echo/confirmation | Match the returned TT Phase 1 Kafka event by origin, causation, occurrence/version, receipt and reservation; advance workflow without another command; confirm authority idempotently | Publish the ordinary Phase 1 final-state event with `origin=resource_booking` after commit | Exact echo match, adapter inbox idempotency and authority confirmation/status |
| 6. Ambiguity/recovery | Query RB workflow, TT receipt/status and authority status; reconcile without blind deletion/release | Expose bounded authenticated receipt/status and safe replay/query controls | Durable workflow/reconciliation evidence; committed-pending scope stays blocking |

## Task ownership mapping

| Timetabler tasks | Resource Booking tasks at pinned commit | Contract area |
| --- | --- | --- |
| 0.1-0.4 | 0.1-0.4 | Exact Phase 1 builds/evidence, external acceptance and named GO approvals |
| 1.1-1.11 | 1.1-1.11 | Topics/schemas/auth, canonical command, identity/time, authority/TTL, lifecycle, fixtures and advice |
| 2.1-2.5 | 2.3, 2.10-2.12; 5.1-5.10 | TT occurrence receipt/config versus RB workflow/outbound state |
| 3.1-3.8 | 4.1-4.12; 5.1-5.2 | Native TT occurrence application versus authority-aware RB booking boundary/command builder |
| 4.1-4.6 | 5.3-5.10; 8.7-8.10 | Dedicated Kafka command role, publisher/consumer, receipt/status and shared fixtures |
| 5.1-5.7 | 2.1-3.12; 4.1-4.12 | RB-owned authority ledger/API and all RB writer enforcement |
| 6.1-6.12 | 3.3-3.10; 4.3-4.8; 8.3-8.6, 8.12 | Mandatory authority gate on every Timetabler writer |
| 7.1-7.6 | 3.3-3.5; 6.10; 8.5, 8.13, 8.16-8.17 | Pre-schedule advice, final engine batch reservation and TTL timing |
| 8.1-8.7 | 6.1-6.10; 8.10-8.11, 8.15 | Echo, workflow recovery, status and reconciliation |
| 9.1-9.6 | 7.1-7.8 | Observability, security, operations, backup and deployment invariants |
| 10.1-10.15 | 8.1-8.18 | Cross-service automated acceptance matrix and Phase 1 regression |
| 11.1-11.9 | 9.1-9.12 | Seeded cutover, canary, acceptance and fail-closed rollback |

## Decisions still requiring approval

The interface roles are agreed, but the following values remain unresolved and must
be closed through section 1 tasks before implementation:

- exact Kafka command/result/DLQ topics, schema versions, headers, partition key,
  retention, payload limits, ACLs and manual-offset policy;
- exact synchronous authority/status and Timetabler receipt/status endpoint paths,
  authentication mechanism, audience/scopes, rate/size limits and credential rotation;
- exact reservation TTL, safety margin, renewal/skew/timeout/retry budgets and fencing
  restore semantics;
- tenant/deployment, academic-term/calendar, typed identity, UTC/local/IANA/DST and
  pending approval/endorsement mappings;
- bulk/recurrence failure outcomes, reactivation/cancellation transitions, advisory
  availability freshness and shared fixture hashes.

## Entry-gate status

Resource Booking Phase 1 release `fc9ecf670d8a1a542cba8b3efe7d1b057779285d`
and deployment run `31078563334` are partial evidence. Coordinated broker/E2E/race,
load/soak, reconciliation/cutover, disaster-recovery, immutable QA evidence and named
Resource Booking, Timetabler, QA, product and operations GO approvals remain missing.
No section 2-11 Timetabler production task is authorized while tasks 0.1-0.4 remain
unchecked.