# Timetabler Implementation and QA Evidence ## Scope implemented - Additive outbox, aggregate-version, engine-receipt, engine-quarantine, durable post-commit delivery, source-scope transport cursor, publisher state, composite transaction metadata, and dead-letter indexes through migrations `0100`-`0102`. - Canonical whole-change-set envelopes, fixed-watermark composite snapshots, replacements/tombstones, deterministic absolute occurrences, request mutation tracking, cascade hooks, applied-response idempotency, replay, publisher, quarantine, reconciliation seed, authenticated HTTP snapshot/health, and operational commands under `api/services/`, `api/models/`, `api/views/`, and `api/management/commands/`. - Request-wide atomicity and rollback-on-error in `AdminApiBase`; post-commit Redis/WebSocket handling and durable legacy/microservice Kafka delivery. - Atomic engine schedule/swap application with validation before transaction, deterministic locks/timeouts, matching receipt no-op, conflicting/protocol quarantine, late matching response processing, manual offset store/commit, rebalance behavior, and feature-gated post-commit `confirmed_schedule`. - Bulk/queryset writer coverage for Staff, Location, activities, bookings, variants/JTA, imports, cascades, week-pattern changes, manual constraint-break, unschedule/resource replacement, management commands, and simulated/legacy/backup dispositions. - Contract, inventory, rollout/rollback/runbook, retention, and Phase 2 hard-gate documentation under `docs/resource_booking/`. - Protected-environment staging deployment enforcement in `.github/workflows/deploy.yml` plus an atomic environment attestor and PM2 singleton start/stop/probe/rollback gate under `deploy/`; publication defaults off and staging activation remains explicit, supervised, and fail-closed. - Guarded pre-existing Staff/Location resource bootstrap under `api/services/integration/bootstrap.py` and `api/management/commands/bootstrap_resource_booking_resources.py`, invoked only by an explicit default-off staging workflow dispatch; it emits no activity events and is safe to rerun. - Stable-key resource projection-revision recovery under `api/management/commands/revise_resource_booking_resource_projection.py`, sharing the resource-only atomic batching service while using finalized outbox origin/request metadata as its retry-safe completion ledger; it does not relax Resource Booking same-version protection. - Privacy-safe, explicit staging Kafka discovery as a read-only `workflow_dispatch` mode in `.github/workflows/deploy.yml` and `deploy/phase1_kafka_staging_diagnostic.py`; it reports classifications/counts/booleans only, verifies the publisher is stopped, and has no publication/bootstrap/revision path. ## QA evidence (2026-08-06, Pacific/Guam) - `python3 -m compileall -q api backend kafka_consumer deploy`: passed. - Ruff 0.15.13 on every changed Phase 1 module (excluding the repository's longstanding `api.models` re-export barrel): passed. Repository-wide Ruff remains pre-existing debt: `origin/dev` has 2,252 errors and this candidate has 2,251; this change adds no Ruff violation. - `manage.py check`: passed, zero issues. `check --deploy` completed with the five pre-existing HSTS/SSL redirect/insecure development secret/secure cookie warnings; this change does not claim those application-wide deployment settings are resolved. - `manage.py makemigrations --check --dry-run`: passed, no drift. - Full clean PostgreSQL 16 migration chain through `api.0102`: passed as part of the clean test database build. - PostgreSQL migration `0101 -> 0100 -> 0101` rollback/reapply passed. Backfill repaired a deliberately missing aggregate-version cursor from immutable outbox v1 evidence, and the next mutation allocated v2 rather than colliding. Additive migration `0102` applied and the deployment gate attested it. - Full repository-discovered Django suite on PostgreSQL 16: **48 tests passed** in 15.649 seconds, with no skips. This includes resource-map SQL, engine replacement/rollback, gap-free concurrent version allocation, exact one-record composite publication, resource-delete-plus-activity grouping, fixed-watermark snapshot grouping/hash/auth, restart-safe preflight, exact provider-fixture SHA, default-off deployment gates, quarantine, durable delivery, replay/order, and writer-bypass guards. - The former `api/tests.py`/`api/tests/` discovery collision was removed by moving the four legacy cases to `api/tests/test_legacy_api.py`; bare repository discovery now runs all 48 tests. - PostgreSQL atomic 500-activity result: **11.475 seconds**, exactly one applied-response receipt, 500 finalized member rows, one source sequence, and transaction count 500. - Matching 500-activity redelivery: **1.912 seconds**, receipt no-op and no second source transaction. - Executable deployment-gate QA passed both branches with fake PM2/probe processes and no broker connection: default-off stopped/deleted the publisher, atomically wrote a mode-0600 environment, reloaded the API, attested migration `0102`, ran preflight and persisted zero publisher instances; enabled-mode issued exactly one `--instances 1` start and passed singleton/liveness; missing enabled configuration failed closed; final QA state was restored to publication/approval/reverse=false. - Current configured engine reservation age is approximately 30 seconds and Kafka `max.poll.interval.ms` is 300 seconds; this local representative run fits both, but it does not replace the required production-like worst-case cross-service performance evidence. - `openspec validate phase-1-outbound-resource-booking-sync --strict`: passed. - `openspec validate phase-2-bidirectional-booking-conflict-control --strict`: passed. ### Pre-existing resource bootstrap repair QA (2026-08-06, Pacific/Guam) - Added the guarded Staff/Location-only bootstrap service and command, explicit default-off workflow-dispatch gate, deployment/runbook coverage, and six OpenSpec acceptance scenarios. No production scheduling writer or activity bootstrap path changed. - Full repository-discovered Django suite on a clean PostgreSQL 16 test database: **64 tests passed** in 21.109 seconds, with no skips. The seven focused bootstrap cases cover active/archived typed state, bounded finalized batching, fixed-watermark inclusion, deterministic snapshot IDs versus live transaction IDs, no fabricated activities, idempotent rerun and stale repair, tombstone retention, injected batch rollback, command safety/output, enabled/reverse refusal, and concurrent single emission. - Executable deployment-gate suite: **15 tests passed** in 3.487 seconds, including ordinary-deploy omission and exactly-once explicit bootstrap invocation under default-off settings, PM2 resolution, warning-prefixed JSON, shell-unsafe dotenv preservation, and rollback behavior. - Python compilation, targeted Ruff, workflow YAML parsing, shell syntax, `git diff --check`, Django system checks, and `makemigrations --check --dry-run`: passed. A clean PostgreSQL migration chain and explicit applied-state attestation through `api.0102` passed; this repair requires no migration. - Strict OpenSpec validation passed for both `phase-1-outbound-resource-booking-sync` and `phase-2-bidirectional-booking-conflict-control`. ### Projection-contract revision recovery QA (2026-08-06, Pacific/Guam) - Focused PostgreSQL 16 resource recovery suite: **12 tests passed** in 6.219 seconds. It proves every current resource advances once using the accepted resource snapshot event types without domain mutation, fixed-watermark selection returns latest v2 members, same-key full retry emits nothing, standard bootstrap afterward emits nothing, no activities are fabricated, tombstones remain authoritative, command confirmation/key validation is enforced, and default-off safety applies to both bootstrap and revision modes. - Partial multi-batch failure test committed the first two v2 resource members, rolled the failed batch back with no cursor/version leak, then reused the same operation key to advance only the remaining v1 member. A further same-key retry emitted zero members; all three aggregates finished at exactly v2. - PostgreSQL concurrent same-key workers emitted exactly one revision member for the shared resource and finished at aggregate version 2/source sequence 2. - Executable deployment-gate suite: **17 tests passed** in 5.277 seconds, including exactly-once explicit projection-revision invocation, stable key forwarding, default-off attestation, and rejection of simultaneous bootstrap/revision flags. - Full repository-discovered Django suite on PostgreSQL 16: **71 tests passed** in 31.432 seconds, with no skips. Clean migrations through `api.0102`, `makemigrations --check --dry-run`, Django checks, compile, targeted Ruff, shell/YAML validation, `git diff --check`, and strict Phase 1/Phase 2 OpenSpec validation passed; no migration is required. ### Privacy-safe staging Kafka diagnostic QA (2026-08-07, Pacific/Guam) - Seven focused tests prove host output is SHA-256 only, legacy host values collapse to bounded classifications, Kafka metadata exposes only classification/count/expected-topic existence, metadata errors cannot leak endpoints/credentials/message text, unsafe publication flags fail the gate, and the workflow passes no RB transport secret or bootstrap/revision/publisher command. - Diagnostic workflow YAML parsing, targeted Ruff, Python compilation, `git diff --check`, and strict Phase 1/Phase 2 OpenSpec validation passed. The diagnostic performs no database migration or production-domain mutation. The disposable PostgreSQL QA container and its synthetic databases were removed after verification. ## Remaining acceptance gates Task status after the coordinated E2E run: **74 of 113 checked**. Tasks 10.1–10.13 are complete; the remaining 39 include all eight LOAD tasks and the non-waivable contract, exhaustive-suite, observability, performance, completion-report, and approval gates. ### Resource Booking evidence update (2026-08-06) - Resource Booking Phase 1 foundation was deployed at `fc9ecf670d8a1a542cba8b3efe7d1b057779285d`; its current v2 receiver release is `a3dcecd0c50daff88bcd030dd5dc039b09d98feb`. - Standard GitHub Actions deployment run [31078563334](https://github.com/Mayvins/resource-booking-be/actions/runs/31078563334) completed successfully for that exact SHA. - Resource Booking recorded 1,258 local tests passing with 48 PostgreSQL-only skips; Ruff, compile, migration drift, Django checks, strict OpenSpec validation, and the separately recorded isolated PostgreSQL Phase 1 suite passed. - The Resource Booking Phase 2 OpenSpec is available on `codex/resource-booking-timetabler-phase-2` at `88c3cd5eaff085c70ab84f4e446b68268c87008b`, with 26 requirements, 72 scenarios, 109 tasks, and strict validation passing. - At that point Resource Booking's acceptance evidence recorded the scoped remaining E2E/load/stability and named approval gates as incomplete. The later coordinated E2E run below supersedes the E2E status only. Disaster recovery has since been explicitly removed from this gate. - Resource Booking v2 receiver `a3dcecd0c50daff88bcd030dd5dc039b09d98feb` is deployed by staging run `31099640196` with ingestion/repair/reverse false. Shared scope `default`, topic `timetabler.activity.events`, and snapshot token configuration are reported present. The exact TT fixture hash is `bf4ae32e685af60415f768fd567fab0423086d5c67ec41dc262142a51e2f2d92`. - Resource Booking adapter repair `1711efe` accepted the fixed-watermark snapshot in reconciliation run `31103172716` with zero unresolved drift and zero quarantine, but reported `resources=0 activities=46 repaired=2 unresolved=0`. This proves the transport/reader path while exposing that pre-existing Timetabler Staff and Location rows had never been captured into the source outbox. - After the Timetabler bootstrap, privacy-safe Resource Booking diagnostic run `31106374425` reported `resources=1794 activities=46 drifts=300 repaired=0 unresolved=300 quarantined=300 outcomes={}` and `drift_codes={"resource_same_version_hash_mismatch":300}`. The 300 earlier version-1 mirrors were produced by the pre-namespaced projection; recovery therefore requires a new source version rather than deletion or relaxed same-version validation. - Timetabler commit `81c96fb523a71ce61baa07bba1c83e5b04e8a071` passed ordinary default-off deployment run `31107445658`, then guarded projection-revision run `31107516468` advanced 1,794 resources in 19 finalized source change sets from watermark 23 to 42. Publication, activation approval, reverse delivery, and transport remained disabled and the publisher remained stopped. This was partial cross-service evidence at the time. The later continuous staging cutover evidence below supersedes its default-off runtime status without changing the historical recovery record. ### Staging source-bootstrap reconciliation and catalogue recovery PASS (2026-08-07) - Resource Booking fixed-watermark reconciliation run `31107759339` against Timetabler watermark 42 completed successfully with `resources=1794`, `activities=46`, 19 source change sets applied, `unresolved=0`, and `quarantined=0`. - The Resource Booking repair gate closed after that run. Resource Booking ingestion and reverse delivery remained false; Timetabler publication, activation approval, and reverse delivery remained false. No live Timetabler publisher was enabled by this recovery. - After Resource Booking frontend commit `f6e1261` and deployment run `31108668644`, live staging UI verification showed all 72 Location rows and the expected 1,722 Staff records. - This evidence closes the prior source-bootstrap, projection-revision, fixed-watermark reconciliation, and empty-catalogue acceptance failure recorded in `docs/resource_booking/phase1-staging-bootstrap-no-go.md`. That document remains a historical incident/recovery procedure, not the current staging catalogue result. This was necessary Phase 1 staging evidence, not the complete Phase 1 acceptance report. The subsequent live Kafka cutover and recovery evidence is recorded below. Tasks 9.5–9.7 remain unchecked and non-waivable. ### Continuous staging Kafka cutover and post-cutover canary PASS (2026-08-07) - Timetabler provider build `a531af1cf74e0d7e10445c0799e71be4816f8ace` supplied the activated canonical v2 publisher path. - The accepted staging architecture is one Kafka record per committed Timetabler source transaction on `timetabler.activity.events`. Its single partition preserves total source order. Timetabler remains authoritative; the Resource Booking-owned adapter owns transformation and atomic mirror application. - Both services attested staging host SHA-256 `c4994701ae04f9730c97104bedbe35a3e03466cf5768d09ee86cc59f2a123b4b`. Their dedicated sync endpoints use the shared loopback broker at `127.0.0.1:9092`; Resource Booking's general Kafka endpoint was not overwritten. - Resource Booking topic-provision run `31112744065` attested one broker, one partition, replication factor one (accepted only for this single-broker staging environment), 30-day delete retention, unclean leader election disabled, and bounded message size. Broker/group diagnostic run `31113864019` passed. - Timetabler diagnostic run `31112956666` confirmed the topic while the publisher was still default-off. Resource Booking commit `ea01f2a` fixed consumer startup by constructing `AIOKafkaConsumer` inside the `asyncio.run()` event loop; bounded probe `31114460845` and activation `31114549544` passed. - Publishing historical Timetabler source sequences 1–42 caused Resource Booking run `31114759974` to fail closed on one historical-cutover quarantine and automatically disable ingestion. No conflict was accepted. Timetabler publication was disabled during recovery, preserving the outbox and watermarks. - Resource Booking fixed-watermark reconciliation run `31115466339` scanned 1,794 resources and 46 activities with `drift=0`, `repaired=0`, `unresolved=0`, and `quarantine=0`. Consumer recovery run `31115622893` was healthy at watermark 42 with lag zero and no quarantine, dead letter, or mirror-only violation. - A post-cutover Timetabler projection canary committed 19 source transactions and advanced the outbox from 42 to 61. Timetabler activation run `31115855194` published through 61 with healthy liveness and zero dead letters. Resource Booking validation run `31115992828` applied all 19 and reported watermark 61, lag zero, no gap, quarantine, dead letter, mirror-only violation, or projection backlog, with readiness `ready/running`. - Final staging flags are Timetabler capture/publish/activation approved `true`, transport `kafka`, reverse delivery `false`; Resource Booking Phase 1 ingestion `true`, repair `false`, reverse `false`. - Together with bootstrap run `31107516468`, reconciliation run `31107759339`, and frontend deployment `31108668644`, this proves ordered continuous staging projection, fail-closed quarantine, fixed-watermark recovery, and gap-free resume. It completes task 9.4 only. Task 9.1 remains conservatively open because its full metrics and write-path-parity clause is not established by this canary. ### Coordinated E2E-01–E2E-13 PASS (2026-08-07) - Run ID `phase1-e2e-20260807-01` completed across both services. Functional runs were Timetabler `31184585822` and Resource Booking `31193533830`; redelivery runs were `31193718861` and `31194322436`. - Synchronized conflict runs Timetabler `31199593913` and Resource Booking `31199568642` submitted in the same millisecond. Timetabler won and committed sequence 114; Resource Booking rejected HTTP 400 with `resource_sync_mode_mirror_only` and committed no contender. - Controlled restart runs `31201102800`/`31201897098` and rollback runs `31202036674`/`31202178039` retained durable checkpoints, restored the exact workers, kept watermark 114, and left reverse delivery false. - Cleanup runs `31202768905`/`31203486498` committed three Timetabler transactions at sequences 115–117, deleting nine activities, seven Staff, and seven Locations. Resource Booking recorded exactly one durable applied receipt per transaction. - Final runs `31204013529`/`31204392182` both finished at watermark 117 with fixtures absent. Resource Booking's complete-snapshot dry run scanned 1,810 resources and 62 activities with drift, unresolved, quarantine, and repair all zero. - Final evidence SHA-256 values are Timetabler `fe3dd7d64002cb04a9ce51d3c587f1155598c6ef6a8ca3e41e6894488bebe087` and Resource Booking `5253eb6ef1e5270cee0bffd59f48166fef3a900cc8bf36c1d1c9124c14d7389a`. - Resource Booking committed its matching acceptance record at `848627a2440ce9c3431d12567a5ffcff069c449e`; deployment `31204948366` passed and its corresponding task 10.4 is checked. This evidence completes Timetabler tasks 10.1–10.13. LOAD was not run and DR remains excluded. Phase 2 production implementation remains hard-blocked: tasks 9.1–9.3, 9.5–9.7, and 10.14–10.21 remain unchecked alongside outstanding contract/ownership/calendar and named Timetabler, Resource Booking, QA, product, and operations approvals. Reverse delivery remains false. ### Guarded Timetabler LOAD harness implemented; execution not started (2026-08-08) - Added the default-disabled Timetabler-owned LOAD-01–LOAD-08 profile executor, exact-source-fence/predecessor-artifact contract, supported-API-only workload drivers, source/canonical-size/publish/host metrics, 2 MiB rollback proof, LOAD-07 publisher-only synchronization fence, cleanup, and read-only final gate. No Resource Booking credential, API, database, or process control is accepted. - Tightened the canonical sequence to read-only attest/entry and current 1,810-resource/62-activity/watermark-117 LOAD-01 evidence before a distinct API-only 1,492-transaction provision stage. The earlier 1,794/46/19 recovery remains run-ID/URL-hashed provenance only. Equal 32-way shards drive a deterministic lifecycle/schedule/reschedule/terminal/recurrence mix and accepted request-start rate fidelity is enforced. - Replaced impossible predeclared future evidence hashes with a fixed predecessor graph and secure mode-0444 predecessor verification. LOAD-07's actual epoch/hash moved to a short-lived, non-circular canonical fence artifact; the immutable manifest retains only lead/skew/ownership policy. - LOAD-04 now requires the jointly approved real maximum activity/member count. LOAD-06 read-only calibrates both exact cases before mutation and requires the accepted envelope within 4 KiB below 2 MiB. Cleanup uses eleven pre-calibrated activity batches plus two bounded resource batches with stable retry identities; no one-shot oversized delete is permitted. - Hard abort cancels queued submissions, preserves a separate hashed failure artifact, treats required process loss as immediate outside the planned restart window, and applies the >90% memory abort only after 300 continuous seconds. The common 12-profile evidence schema includes full configuration, predecessor, metrics, assertions, and no-touch safety fields. - Complete canonical evidence is written under `/var/tmp/mayvins-timetabler-phase1-load`: uid-1073 root/run directories are mode `0755`, while uid-1073 canonical evidence/fence files are mode `0444` for the attested uid-1069 RB reader. The immutable manifest and read-only attestation bind the path hash, UIDs, modes, and credential prohibition. Identical retries may reuse exact bytes; different bytes, credentials, ownership/mode drift, or contradictory hashes fail closed. Only the SHA-256 and bounded locator metadata are printed by the workflow. - The checked-in example remains `approved=false`; LOAD-05 is canonically 32 recurrence activities × 12 weeks = 384 occurrences but retains an unapproved example reference, and no short-lived LOAD-07 fence artifact exists. The workflow defaults to `none` and is mutually exclusive with deployment, diagnostic, bootstrap/revision, and E2E modes. - Added a separate guarded `arm-fence` workflow action. It requires the exact sealed LOAD-06 predecessor SHA and unchanged LOAD-07 source fence, validates the 60–900-second lead and approved window, then creates or identically reuses the canonical uid-1073 mode-0444 fence. The artifact binds both exact commits, epoch, cryptographic nonce, real approval reference, timestamps, and one non-circular `coordination_sha256`. This action emits the digest and performs no load, process restart, database mutation, or domain mutation; LOAD-07 remains the sole publisher-restart stage. - Added explicit timezone-qualified source transaction serialization and the guarded immutable `correct-provision-evidence` path for the one sealed offset-less PROVISION artifact. The original stays mode-0444 and unchanged; the corrected mode-0444 artifact is linked by the exact shared declaration, current commits, watermark/publisher health, and complete fixture inventory. The action performs no authentication, API/restart/load/domain/database/ outbox mutation, DR, or reverse delivery, and LOAD-02 resolves it only when declared. Follow-ups permit exactly `provision-corrected.json`, `provision-corrected-v2.json`, `provision-corrected-v3.json`, `provision-corrected-v4.json`, `provision-corrected-v5.json`, `provision-corrected-v6.json`, or `provision-corrected-v7.json`, so an immutable earlier correction is never overwritten during receiver-only recovery. - LOAD-02 now permits only a verified partial-prefix resume: fixed entry/final fences remain unchanged, durable source rows must be an exact contiguous finalized/published deterministic prefix, only remaining iteration IDs are submitted, and combined evidence must contain the complete 3,600-transaction profile. API/lock/rate/host metrics explicitly cover only the active segment. - The guarded `checkpoint-load-02` action is read-only and fixed to the active recovery run. It verifies the corrected PROVISION predecessor and exact finalized/published deterministic prefix before sealing immutable mode-0444 checkpoint evidence; it has no mutation, load, restart, database-write, RB, Phase 2, reverse, or DR capability. - PROVISION correction now accepts a source watermark inside the LOAD-02 fence only after the same prefix proof. The historical PROVISION source transaction list remains unchanged while current prefix count/digest are disclosed in a separate progress attestation. - This implementation and local contract QA complete no load acceptance task. Tasks 10.14–10.21 remain unchecked; no staging deployment, fixture mutation, load profile, Resource Booking verification, or DR exercise was run. ### Failed LOAD-02 read-only engine containment audit (2026-08-09) - The first LOAD-02 run is retained as failed. Its observed source-only pattern cannot prove schedule completion because HTTP `schedule-request` returns after durable enqueue, its `PostCommitDelivery.delivery_id` becomes the engine/Kafka request ID, and the engine response may arrive after subsequent same-shard reschedule/unschedule calls. No absent source transaction is relabelled or fabricated. - Added default-disabled `audit-failed-load-02-engine-work`, fixed to the failed run and false mutation/operational confirmations. It resolves only run-owned fixtures, performs two bounded stable ORM reads, and correlates privacy-safe API-log identifier summaries, post-commit correlations/generated UUIDs, Kafka request/response state, applied receipts, quarantine, complete published change sets, and hashes/counts of only run-owned activity final states. - Output reports expected/accepted/applied/failed/no-op/ambiguous counts per workload class. The admin API log schema lacks `X-Request-ID`, so its evidence is exact by class rather than per iteration; engine scheduling retains exact per-request correlation through the durable delivery UUID. Missing, duplicate, incomplete, unpublished, contradictory, or uncorrelatable state remains ambiguous. Any unresolved engine chain sets `all_engine_work_terminal=false` and `late_mutation_possible=true`; quarantine retains explicit operator-replay risk. - The action authenticates to no API, writes no evidence/application/database/ outbox state, publishes no Kafka message, changes no process, performs no cleanup/load/DR, and cannot enable reverse delivery or Phase 2. LOAD-02 stays failed and cleanup stays prohibited regardless of audit outcome. - Local QA: focused contract suite **58 tests passed**; full PostgreSQL-backed Django suite **186 tests passed**; clean PostgreSQL 16 migrations through `api.0103`, migration no-drift, Django checks, Python 3.12 compilation, changed-code Ruff, workflow YAML parsing, `git diff --check`, and strict Phase 1/Phase 2 OpenSpec validation passed. Repository-wide Ruff remains a pre-existing baseline failure (2,328 findings outside this change); no unrelated lint files were modified. ### Engine-aware LOAD-02 correction (2026-08-09) - A second staging attempt reproduced the documented asynchronous mismatch: all 515 Staff and 515 Location lifecycle transactions published, while all 1,542 schedule/reschedule requests terminated as engine failure/no-slot and both 514-operation unschedule classes were no-ops. The run remained failed; no missing activity transaction was fabricated or relabelled. - The manifest-bound read-only audit proved all 1,542 engine operations terminal, zero ambiguity/quarantine/replay risk, and no late mutation. The guarded supported-API cleanup then removed only run-prefixed fixtures at the exact 5,175--5,188 fence, preserving authoritative term-26 IDs 672--716. - Rate traffic now waits inside each fixture shard for the full durable engine chain: unique post-commit delivery, valid Kafka response, atomic applied receipt, and exactly one finalized/published source transaction. Dependent reschedule/unschedule calls cannot overtake engine completion. - Engine-applied transactions are attributed by delivery UUID; synchronous transactions retain the client request ID. Completion may reorder between shards, so acceptance proves a complete request/transaction bijection rather than an invalid global sequence-to-iteration ordering assumption. - Engine-aware LOAD-02 partial execution is non-resumable. A partial run must follow the read-only containment audit and supported-API abandoned cleanup path before a fresh run. This preserves conflict prevention and prevents duplicate engine submission. ### Engine-feasible load provisioning correction (2026-08-09) - The engine-aware rerun proved the ordering correction but remained failed: 1,030 Staff/Location lifecycle transactions applied while all 1,542 final schedule/reschedule operations returned terminal no-slot results. A bounded audit proved zero ambiguity/quarantine/late mutation, supported APIs cleaned the failed run at source fence 7,710--7,723, and Resource Booking then proved zero lag, backlog, quarantine, dead letter, or reconciliation drift. - Code review found a deterministic fixture-feasibility gap. Provisioning chose the academic term's first available slots and first 12 weeks but did not require the selected template's module to teach those weeks or permit those slots. The Scheduling Engine explicitly blocks every slot when the module week set is empty/incompatible and ORs module unavailability into the final activity bitmap. - Provisioning now rejects inactive/cross-term/incompatible modules, requires all 12 recurrence weeks in the module's effective custom/named week pattern, and chooses two slots from the term/module availability intersection. - After the first dedicated Staff+Location+activity fixture exists, provisioning sends one stable-id advice-only pre-schedule canary through the real engine. Both exact LOAD-02 slots must have positive engine preference before any remaining activity fixtures are created. The canary must produce one valid durable delivery/response, no quarantine, and no source-watermark change; scheduling, Resource Booking writes, reverse delivery, Phase 2, and DR stay disabled. - Focused local QA passed all 67 load-harness tests plus compile, Ruff, and diff checks. This closes only the harness implementation task; a new staging canary, full provision, cross-service evidence chain, and LOAD-01--LOAD-08 executions remain required before Phase 2 can unlock. ### Entry-gate local QA refresh (2026-08-06) - Isolated environment: Python 3.12.13 with the repository's 27 pinned packages. The same requirements cannot install unchanged on local Python 3.14 because `psycopg2-binary==2.9.10` has no matching wheel and `pg_config` is absent; no dependency was changed. - `compileall`, focused changed-code Ruff, Django checks, and migration-drift checks: passed. - Bare repository test discovery is repaired and passed all **48 PostgreSQL tests** with no skips. - Clean PostgreSQL 16 migration chain through `api.0102` passed; `0101 -> 0100 -> 0101` rollback/reapply, legacy aggregate-version cursor repair, and `0102` apply passed. - Local PostgreSQL 500-activity atomic apply: **11.475 seconds**, one receipt, 500 finalized members and one source sequence. Matching duplicate: **1.912 seconds**, no second receipt/transaction. - Default-off, enabled singleton, liveness and failure-rollback deployment paths passed against fake supervisor/probe processes; no broker connection or real publication occurred and the final state was disabled. - Synthetic eligible claim over 10,500 outbox rows: PostgreSQL used an index scan/incremental sort and returned 100 rows in **0.113 ms execution time** after `ANALYZE`. - Executable provider/consumer probe: Resource Booking `fc9ecf670d8a1a542cba8b3efe7d1b057779285d` rejected a representative Timetabler envelope with `ContractError` for unknown `actor_id`, `aggregate`, `change_set_id`, `committed_at`, `committed_state`, `event_version`, `ordering_key`, `origin`, and `request_id` fields. The local results are valid evidence for the narrow paths they execute. The staging bootstrap failure identified by the point-in-time audit has since been repaired and reconciled as recorded above. The coordinated E2E plan has also passed, but these results do not satisfy the unchecked exhaustive writer/failure/crash/observability tasks or the load/stability plan. See `docs/resource_booking/phase1-entry-gate-audit-2026-08-06.md` for the historical entry-gate state. Unchecked tasks remain deliberately open where the coordinated E2E evidence does not satisfy the full task: final cross-service contract decisions, remaining adapter transformation/occurrence/idempotency acceptance, dashboards/alerts and joint runbooks, all eight load/stability runs, production-like worst-case engine reservation/max-poll timing, completion report, and named approvals. DR is explicitly excluded. Phase 2 production implementation remains hard-blocked. The Timetabler implementation and local QA in this file are necessary evidence, not the cross-service Phase 1 completion report required by tasks 9.5–9.7.