# Deterministic HTTP prepared-candidate regression

The immutable source7 Linux gate passed the catalog GET and competing PATCH two-second assertions, but its deliberately expensive nested-source request reached the real production30-second deadline and returned504 instead of412. An isolated rerun reproduced it (49.38s test duration, cached build14.01s), so it is not classified as a random failure. The original100ms/unfinished-client observation did not prove that the server had passed its initial revision check.

The replacement uses the production router, loopback TCP, Reqwest and the real source parsing/migration/validation/updater path. A private `cfg(test)` per-Store gate is consumed once for its exact resource and ETag, after `PreparedProject::replacement` succeeds and before the catalog commit lock is acquired. The observer receives the actual prepared model and source bundle and recompiles the latter for equality. Only then does it issue the catalog GET and competing PATCH, each still bounded to two seconds. The candidate remains pending until explicit release. Its final response must be exactly412, `revision_conflict`, current revision2; the accepted complete model, ETag and persisted model/source envelope must retain the winner.

The gate mutex is released before waiting. Explicit release permits the normal commit recheck; RAII guard drop cancels without installing anything, with a focused cancellation regression. The blocking wait has a15-second ceiling, preparation/release observations have10-second watchdogs, and server shutdown is bounded. There is no production configuration, timeout, dependency or public API change: the gate field, call, support module and real-TCP test are compiled only for library unit tests. The obsolete timing-dependent integration test alone is removed; existing store commit-conflict tests remain.

This strengthens proof of an actual fully prepared stale candidate overlapping a newer HTTP commit and an available catalog while that worker is paused. It is not a sustained CPU throughput benchmark and does not promise that every admitted model finishes in30seconds. Accepting either504or412, retry-until-pass, platform-specific fixture shrinking, raising the production deadline, or raising only the client watchdog were rejected.

Implementation files: `crates/oa-server/src/store.rs`, `src/store_preparation_gate.rs`, `src/preparation_http_tests.rs`, the test-module declaration in `src/lib.rs`, and the single removed fixture in `tests/http.rs`.

Verification at preparation checkpoint: rustfmt and scoped `git diff --check` pass. Cargo has not been run; the Linux source snapshot and its failed test evidence remain unchanged. Required filters after the shared resource lease is released:

```text
cargo test --locked -p oa-server --lib prepared_source_http_rechecks_revision_without_holding_catalog
cargo test --locked -p oa-server --lib preparation_gate_drop_cancels_without_installing_candidate
```

Moving the regression into the library changes target distribution, not its real-HTTP nature; the extra guard-drop test increases the overall test inventory by one.

Windows execution on 2026-09-07 passed both focused regressions (HTTP 0.07s test runtime; cancellation 0.06s), then all server targets: 4 library + 50 HTTP + 2 state tests, 56 passed, zero failures/ignored. Full-server command took 68.78s, including compilation. Workspace formatting passed and strict workspace/all-target Clippy passed in 99.60s. All recorded exit codes are zero in `.local/source7-post-routing-gates-status.json`; logs are `.local/source7-server-prepared-http-focused.log`, `.local/source7-server-preparation-cancel-focused.log`, `.local/source7-server-post-preparation-all-targets.log`, and `.local/source7-post-routing-clippy.log`.

The corrected server delta still requires native Linux execution. The fresh immutable 458-file snapshot `source7-20260907T082753190288Z.tar.gz` has SHA256 `cbb371a93a562e1e641d7629fe351e016d63e66fc9112499b3fed6d5cd171f78`; it includes the corrected server regression and desktop routing. Earlier frozen Linux failures remain unchanged and are not reclassified by these Windows passes.