## ADDED Requirements

### Requirement: Outbox delivery is durable, transaction-atomic, globally ordered, and retryable
Every finalized Timetabler change set SHALL receive one positive globally commit-ordered source sequence within its source scope. The publisher SHALL publish exactly one complete canonical transport envelope and one Kafka record for that change set, keyed by source scope, containing all member final-state events and one transaction hash. It SHALL NOT publish member outbox rows as independently complete transactions. Status, attempts, retry, acknowledgement, replay, and dead-letter transitions SHALL apply to the complete change set, and an incomplete/failed sequence SHALL block every later sequence in the scope.

#### Scenario: Transient adapter failure
- **WHEN** publishing a composite change-set envelope fails with a retryable error
- **THEN** every member remains durable in the same retry state with a sanitized error and scheduled retry, no member is acknowledged alone, and later source sequences remain blocked

#### Scenario: Earlier source transaction is pending
- **WHEN** source sequence N is not successfully delivered and sequence N+1 is otherwise eligible
- **THEN** sequence N+1 is not published until N is atomically acknowledged or its full audited replay succeeds

#### Scenario: Change set has multiple allocation members
- **WHEN** one engine response or resource deletion commits multiple activity/resource outbox members
- **THEN** all members have one source sequence and are emitted in one bounded outer envelope with `transaction_count`, `complete=true`, and one hash/Kafka record

#### Scenario: Retry budget is exhausted
- **WHEN** a change set exceeds the configured retry policy
- **THEN** every member enters dead-letter state as one blocked transaction, remains queryable with full audit metadata, and triggers an alert

### Requirement: Operator replay is safe and auditable
Operators SHALL replay the complete failed/dead-lettered source transaction under its same immutable transaction ID and source sequence without editing member payload/history. Replay SHALL record operator, reason, correlation, and outcome.

#### Scenario: Dead-letter event is replayed
- **WHEN** an authorized operator replays a corrected/recoverable dead-letter delivery
- **THEN** all members retry together under the original outer event/transaction ID and source sequence, the attempt is audited, and adapter idempotency prevents duplicate mirror state

#### Scenario: Already-applied event is replayed
- **WHEN** an already-applied source event is replayed during recovery
- **THEN** Resource Booking/adapter recognizes the event ID/version and leaves the mirror unchanged while recording the acknowledgement

### Requirement: Reconciliation detects missing, stale, and orphaned mirrors
Timetabler SHALL provide a service-authenticated, bounded snapshot at one fixed committed source-sequence watermark. It SHALL select the latest member state per canonical aggregate at that fence, group latest members by their originating change set/source sequence into the same outer transport contract, emit at most one independently hashed envelope per sequence in strict sequence order, and never include a member above the watermark. The Resource Booking-owned adapter SHALL compare those facts with RB mirrors and identify missing, stale, and orphaned records without Timetabler learning RB schemas.

#### Scenario: Snapshot members share an originating sequence
- **WHEN** multiple latest aggregate states originated in one finalized change set at or below the fence
- **THEN** the snapshot returns one composite envelope for that sequence with one outer hash rather than separately hashed envelopes at the same source watermark

#### Scenario: Only some original members remain latest
- **WHEN** a later change supersedes some but not all aggregate members from an earlier source transaction
- **THEN** the earlier snapshot composite contains only its members still latest at the fence, remains one complete snapshot envelope for that sequence, and no returned member exceeds the fixed watermark

### Requirement: Pre-existing Staff and Location resources can be bootstrapped safely
Timetabler SHALL provide a guarded, resource-only bootstrap that captures every current Staff and Location canonical final state missing from or stale in the finalized outbox. The bootstrap SHALL preserve typed source identity, allocate only the next aggregate version and global source sequence, finalize each bounded change set in the same database transaction as its members, and be idempotent by canonical current-state hash. It SHALL run only while publication, activation approval, and reverse delivery are disabled; SHALL NOT fabricate activity events; and SHALL retain existing tombstones for source rows that no longer exist.

#### Scenario: Resources predate the integration outbox
- **WHEN** active or archived Staff and Location rows exist without finalized canonical outbox state
- **THEN** the bootstrap emits exactly one typed final-state member per resource in bounded finalized transaction-atomic change sets with positive globally ordered source sequences, and the fixed-watermark snapshot includes every committed member

#### Scenario: Resource bootstrap is rerun
- **WHEN** the guarded bootstrap runs again and the canonical resource state has not changed
- **THEN** it skips the resource without incrementing its aggregate version, creating another change set, or emitting an activity member

#### Scenario: A direct writer left stale resource state
- **WHEN** a current Staff or Location row differs from its latest finalized canonical outbox state
- **THEN** the bootstrap appends one replacement at the next aggregate version with the prior and current canonical states and leaves ordinary scheduling workflows unchanged

#### Scenario: A deleted source already has a tombstone
- **WHEN** the latest finalized state is a tombstone and the corresponding Staff or Location row no longer exists
- **THEN** the bootstrap retains that tombstone and does not recreate a source row or replacement event

#### Scenario: Bootstrap batch finalization fails
- **WHEN** any member append, version allocation, sequence allocation, or change-set finalization fails
- **THEN** the whole database batch rolls back with no partially visible outbox members, version increments, or cursor advancement

#### Scenario: Snapshot and live transaction identifiers are distinguished
- **WHEN** a fixed-watermark snapshot contains only the latest members originating from a source transaction
- **THEN** it may use one deterministic snapshot `event_id` distinct from `source_transaction_id`, while the complete live envelope continues to require `event_id` equal to `source_transaction_id`

### Requirement: Projection-contract revisions are explicit, versioned, and retry-safe
Timetabler SHALL provide a separate guarded one-shot operation for an approved Resource Booking projection-contract revision. For every current Staff and Location aggregate, it SHALL re-emit the canonical final state using the existing accepted snapshot event type at exactly the next aggregate event version, without mutating the domain resource or emitting any activity member. The operation SHALL require a stable operator-supplied idempotency key, record that key and a projection-revision origin on every member, run only while publication, activation approval, and reverse delivery are disabled, and use the existing finalized outbox as its durable completion ledger.

#### Scenario: A projection revision is approved
- **WHEN** an operator explicitly dispatches a new stable projection-revision operation key after the resource bootstrap
- **THEN** every current Staff and Location advances exactly one event version in bounded, finalized, globally sequenced transaction-atomic change sets, and a fixed-watermark snapshot selects those latest canonical members

#### Scenario: The same operation key is retried
- **WHEN** workflow retry or operator recovery invokes a projection-revision key that already finalized some or all resource members
- **THEN** completed aggregates are skipped without another version increment and only aggregates lacking a finalized member for that key are emitted

#### Scenario: A projection-revision batch fails
- **WHEN** member append, version/sequence allocation, or finalization fails for one bounded batch
- **THEN** that whole batch rolls back while prior committed batches remain retryable under the same operation key without double-versioning

#### Scenario: A source resource has already been deleted
- **WHEN** a Staff or Location row is absent and its latest canonical state is a tombstone
- **THEN** projection revision retains the tombstone, does not recreate or re-emit the deleted resource, and does not alter its aggregate version

#### Scenario: The same projection revision runs concurrently
- **WHEN** two workers use the same operation key for an overlapping resource batch
- **THEN** deterministic resource and aggregate locking plus the finalized operation-key ledger allow exactly one next-version member per aggregate

#### Scenario: Ordinary bootstrap follows projection revision
- **WHEN** the standard canonical bootstrap runs after the projection-revision states are finalized
- **THEN** canonical hash comparison treats every unchanged current resource as up to date and emits no further event

#### Scenario: Mirror is missing
- **WHEN** a canonical Timetabler identity/version has no corresponding RB mirror
- **THEN** reconciliation reports it and schedules targeted canonical replay/application

#### Scenario: Mirror is stale
- **WHEN** the RB mirror has an earlier Timetabler source version
- **THEN** reconciliation reports the version gap and repairs it with the latest canonical replacement state

#### Scenario: Mirror is orphaned
- **WHEN** an RB mirror references a Timetabler source identity absent/tombstoned in the canonical manifest
- **THEN** the adapter reports and removes/archives it according to the source-tagged cleanup contract without Timetabler querying RB tables

### Requirement: Integration operations are observable
The system SHALL expose structured logs, metrics, traces, dashboards, and alerts for outbox lag/state, publish latency/errors, dead letters, response idempotency, apply timing/locks, consumer offsets/rebalances, post-commit effect failures, and reconciliation divergence. Telemetry SHALL carry event/change-set/request/correlation IDs and SHALL avoid secret/sensitive payload leakage.

#### Scenario: Outbox lag breaches threshold
- **WHEN** the oldest pending event age exceeds the configured service objective
- **THEN** an alert identifies the environment/tenant, lag, queue depth, and diagnostic correlation fields

#### Scenario: Receipt hash mismatch occurs
- **WHEN** a duplicate request ID arrives with conflicting content
- **THEN** a high-severity structured event and metric are emitted without logging sensitive payload bodies

#### Scenario: Reconciliation diverges
- **WHEN** missing, stale, or orphan counts exceed the agreed threshold
- **THEN** rollout/operations are alerted and the affected identities can be exported for targeted repair

#### Scenario: Operator discovers staging Kafka availability
- **WHEN** an authorized operator explicitly dispatches the Phase 1 staging Kafka diagnostic
- **THEN** the workflow emits only a SHA-256 fingerprint of the configured staging host, loopback TCP availability, broker/topic metadata classifications and counts, expected-topic existence, legacy host classification, default-off integration flag booleans, and publisher-stopped attestation; it emits no host, endpoint, credential, topic name other than the agreed expected topic, or message data and performs no publish/bootstrap/revision action

### Requirement: Rollout and rollback preserve authoritative state
Phase 1 SHALL use additive schema, feature flags, staged outbox capture/publishing, source-tagged seed/reconciliation, and mirror-only Resource Booking controls. Rollback SHALL stop publication/application safely without deleting outbox history, renumbering versions, or re-enabling conflicting RB writes.

#### Scenario: Publisher is disabled during rollout
- **WHEN** outbox capture is enabled but Resource Booking publication is feature-disabled
- **THEN** Timetabler continues to record ordered pending events that can be published after the adapter is ready

#### Scenario: Staging deployment is not approved for publication
- **WHEN** the staging deployment runs without both publication and activation approval enabled, or with incomplete Phase 1 broker/authentication configuration
- **THEN** the deployment transports and attests the safe Phase 1 settings, keeps reverse delivery disabled, leaves exactly zero publisher processes running, and keeps capturing complete source transactions

#### Scenario: Publisher activation or deployment probe fails
- **WHEN** configuration validation, migration attestation, publisher startup, singleton verification, or liveness probing fails
- **THEN** the deployment stops the supervised publisher, atomically forces publication and activation approval false, reloads the API environment, persists the stopped process state, and fails the deployment

#### Scenario: Rollback is required with in-flight engine responses
- **WHEN** the atomic consumer must be rolled back
- **THEN** response consumption is paused, in-flight/receipt/offset state is reconciled, and rollback does not create an ambiguous double application

#### Scenario: Adapter rollout fails
- **WHEN** adapter application is stopped after some mirrors were seeded
- **THEN** those records remain source-tagged/mirror-only, outbox history is retained, and controlled reconciliation determines cleanup or resume

### Requirement: Phase 2 implementation has a hard evidence gate
No Phase 2 production-code implementation SHALL begin until Phase 1 implementation is complete and the full Phase 1 unit, integration, regression, failure-injection, concurrency, and performance tests have passed for both Timetabler and Resource Booking/adapter, reconciliation acceptance has passed, and an approved completion report records the evidence.

#### Scenario: Any Phase 1 evidence is incomplete
- **WHEN** a Phase 2 implementation task is proposed while either service has an incomplete/failing required Phase 1 suite, missing reconciliation evidence, or unapproved completion report
- **THEN** the Phase 2 task remains blocked and no Phase 2 production code is started

#### Scenario: Gate is approved
- **WHEN** both service owners approve the versioned Phase 1 completion report with all required evidence and rollback readiness
- **THEN** the recorded dependency may be marked complete and Phase 2 implementation may begin under its own change plan

### Requirement: Phase 1 acceptance is cross-service
Phase 1 SHALL NOT be declared complete solely from Timetabler unit tests. Acceptance SHALL include Resource Booking adapter contract/application tests, end-to-end replacement/tombstone behavior, mirror-only conflict prevention, reconciliation, performance, and operational exercises.

#### Scenario: Timetabler tests pass but adapter tests fail
- **WHEN** all Timetabler tests pass but the adapter/RB suite, reconciliation, or mirror-only conflict test fails
- **THEN** Phase 1 remains incomplete and the Phase 2 gate remains closed

### Requirement: Remaining E2E and load acceptance is bounded and non-production
The remaining coordinated Phase 1 gate SHALL execute the versioned `E2E-01` through `E2E-13` and `LOAD-01` through `LOAD-08` plan only in an approved non-production environment, using supported APIs and unique run IDs. Reverse delivery and Phase 2 SHALL remain disabled. Production or unrelated data, direct database mutation, and filtered final reconciliation SHALL NOT be used to obtain a passing result.

#### Scenario: Planning is recorded before execution
- **WHEN** the Timetabler plan is aligned to Resource Booking commit `ddeca51` but no scoped run has executed
- **THEN** every E2E/load execution task remains unchecked, Phase 1 remains incomplete, and Phase 2 remains blocked

#### Scenario: Performance thresholds are evaluated
- **WHEN** a scoped E2E, steady, burst, boundary, restart-under-load, or stability run completes
- **THEN** end-to-end p95 is at most 5 seconds and p99 at most 15 seconds, lag drains within 5 minutes, RB apply p95 is at most 2 seconds and p99 at most 5 seconds, Timetabler lock-wait p95 is at most 500 ms with no unhandled deadlock, booking API p95 impact is at most 20% with error-rate increase below 0.1 percentage point, and CPU/memory have no sustained period above 80%, unless a stricter or jointly approved replacement was recorded before execution

#### Scenario: A correctness invariant fails
- **WHEN** any scoped run records an accepted conflict, partial apply, unexplained drift, mirror-only violation, sequence gap, unresolved quarantine/dead letter, final backlog, or reverse delivery
- **THEN** the run fails, evidence is preserved, execution stops safely, and no repair or filtering converts that result into a pass

#### Scenario: An interrupted LOAD-02 prefix is checkpointed
- **WHEN** the fixed recovery run is inside its open LOAD-02 fence and every source sequence is the exact deterministic finalized and published request prefix
- **THEN** a read-only action may seal one immutable full-prefix checkpoint with current commits, predecessor evidence, source safety metrics, canonical transaction digest, and explicit no-mutation/no-load/no-restart assertions

#### Scenario: An interrupted LOAD-02 prefix is unsafe
- **WHEN** the watermark is outside the open fence or any source sequence is missing, unrelated, duplicated, unfinalized, or unpublished
- **THEN** checkpoint and correction both fail before writing evidence and no load, domain, database, outbox, process, reverse-delivery, or Phase 2 action occurs

#### Scenario: Unsafe LOAD-02 attribution is diagnosed without disclosure or mutation
- **WHEN** strict prefix attribution fails and an operator invokes the fixed-run diagnostic with false mutation and operational confirmations
- **THEN** Timetabler reports only the first unexpected sequence, structural state, safe same-run suffix or request hash/classification, complete bounded numeric present/missing/duplicate/out-of-range inventory hashes and ranges, and two-read stability; writes no evidence or application state; and keeps resume/correction prohibited

#### Scenario: Failed asynchronous LOAD-02 engine work is audited before cleanup
- **WHEN** the fixed failed run has HTTP-accepted Scheduling Engine requests whose final application cannot be inferred from client request IDs or source-watermark deltas
- **THEN** a no-credential, two-read action correlates bounded API-log identifiers, post-commit correlations/generated delivery UUIDs, Kafka request/response terminal state, applied receipts, quarantine, complete published outbox change sets, and only run-owned activity final-state hashes; reports exact accepted/applied/failed/no-op/ambiguous counts by workload class; declares any unresolved or contradictory chain nonterminal with late mutation possible; performs no evidence/application/database/outbox/process/Kafka/domain mutation; and keeps load acceptance, cleanup, reverse delivery, Phase 2, and DR disabled

#### Scenario: Existing scheduled term state is backfilled without domain mutation
- **WHEN** the approved read-only plan proves exact term 26, source fence 2639, activity identities 672 through 716, 45 scheduled final states, truthful typed allocations, deterministic absolute occurrences, healthy Phase 1 publication, and one complete canonical transaction below the byte limit
- **THEN** Timetabler MAY use its ordinary outbox capture service to finalize exactly one idempotent 45-member activity-snapshot source transaction while changing no activity, allocation, week, Staff, Location, engine, Resource Booking, reverse-delivery, Phase 2, load, or DR state; any plan/fence/domain/configuration/database/size drift rolls the complete outbox/version/cursor attempt back

#### Scenario: A scheduled activity has Location but no Staff allocation
- **WHEN** the exact reviewed source state for activity 686 or 690 contains a Location allocation and an empty Staff allocation array
- **THEN** the canonical member preserves that typed state without fabricating Staff, and Resource Booking either atomically accepts the supplied typed resources under its validated contract or rejects the complete source transaction without partial application

#### Scenario: Historical PROVISION evidence is rebound after LOAD-02 begins
- **WHEN** current source progress is a fully verified deterministic LOAD-02 prefix
- **THEN** correction retains only the historical PROVISION transactions and records the later watermark, prefix count, and prefix digest in a separate progress attestation

#### Scenario: Operational recovery is exercised
- **WHEN** a controlled publisher/consumer restart or application/release/configuration rollback is performed
- **THEN** checkpoints and durable history are retained, delivery resumes without loss or duplicate application, lag drains within 5 minutes, and unfiltered reconciliation reaches the zero-correctness state

#### Scenario: Disaster recovery work is proposed for this gate
- **WHEN** database backup/PITR restore, Kafka cluster rebuild/restore, host/AZ/region/site failover, infrastructure/DNS/secrets-vault rebuild, or multi-region/business-continuity exercise is proposed as Phase 1 acceptance work
- **THEN** it is rejected as out of scope without removing the required controlled restart, application rollback, checkpoint recovery, durable resume, or reconciliation tests