Polymarket Rust production cutover: bounded preflight, 900-second Gate, and CI lanes

[proerror77]

Problem Statement

The production Polymarket reference collector and upload services still run
Python even though the exact Rust candidate has repeatedly passed data and
artifact checks. The release Gate mixes slow preflight, settlement maturity,
Python-cycle admission, and Rust observation into one long timer. This makes a
nominal 15-minute release take much longer and obscures whether a failure belongs
to the artifact, Python baseline, Rust runtime, data compatibility, or CI.

Solution

Separate bounded preflight from a strict 900-second Rust observation Gate. Before
the timer, verify immutable release bindings, production unit safety, current
policy-clean Python health and identity, and a real mature closed segment through
the candidate uploader and OSS readback. During the timer, keep Python identity
stable without waiting for a new Python cycle, continuously verify Rust runtime
and data health, and evaluate Rust-self evidence produced during the 900 seconds.
After success, finalize and read back evidence, atomically cut over the three
services, verify the running Rust binary identities, and retain automatic Python
rollback. Independently simplify CI into release-critical and non-blocking lanes
so unrelated checks cannot hide the actual deployment state.

User Stories

1. As the production controller, I want preflight to fail within about five minutes, so that a bad candidate never consumes a long Gate window.
2. As the production controller, I want the formal Rust Gate to last exactly 900 seconds, so that a 15-minute approval means 15 minutes of observation.
3. As the production controller, I want current Python health checked before the Gate, so that rollback begins from a known policy-clean baseline.
4. As the production controller, I want Python PID, invocation, and restart identity stable during the Gate, so that the comparison and rollback baseline cannot silently change.
5. As the production controller, I do not want to wait for another Python full-catalog cycle, so that Python cadence does not extend the Rust Gate.
6. As the production controller, I want a real mature closed segment tested before the Gate, so that settlement, format, upload, and OSS compatibility are proven outside the live timer.
7. As the production controller, I want Rust-self evidence over the 900-second spool, so that the Gate remains valid when Python emits no comparable rows.
8. As the production controller, I want Rust health, process identity, resource pressure, rotation, deduplication, and data progress checked continuously, so that a superficially alive process cannot pass.
9. As the production controller, I want final manifests, hashes, and OSS objects independently read back, so that local success cannot substitute for durable evidence.
10. As the production controller, I want all three production services cut over atomically and verified from procfs, so that systemd configuration cannot misstate the running binary.
11. As the production controller, I want automatic rollback to the verified Python control on post-cutover failure, so that release failure is recoverable.
12. As a maintainer, I want release-critical CI separated from unrelated monorepo work, so that merge state names the actual blocker.
13. As a maintainer, I want CI restructuring independently mergeable and rollbackable, so that it cannot delay the collector cutover.

Implementation Decisions

• The deployment Gate and its evidence policy remain the single code-level test seam.
• Preflight receives one wall-clock deadline of 300 seconds; nested operations consume that shared budget and fail closed when it expires.
• Legacy-Python admission requires one current policy-clean atomic health publication before shadow start and captures PID, invocation ID, restart count, unit identity, and command identity.
• Legacy Python identity remains stable for the complete Gate, but no post-start Python health completion is required.
• The formal observation timer is 900 seconds total. It does not include artifact build time, operator scheduling, or final evidence upload, and it does not append a settlement-maturity tail.
• Mature closed-segment preflight owns settlement and upload compatibility. The formal Gate owns live Rust process/data stability and Rust-self consistency for its newly produced spool.
• Rust-self evidence remains fail closed: positive required record classes, valid required fields, deduplication, rotation, metadata context, and exact candidate identity remain mandatory.
• Final cutover stays a separate runtime promotion step after immutable Gate evidence independently validates.
• CI layering is a separate rollout unit from the Gate behavior and cannot block the exact artifact build once the Gate fix is merged.
• Research, snapshot construction, evaluator/MCTS, and issue Capture full-update Polymarket CLOB evidence for token microstructure research #235 remain untouched.

Testing Decisions

• Use the existing control-plane integration script to exercise the public Gate and policy boundary.
• Add counterexamples for preflight deadline expiry, stale or missing Python health, Python identity drift, a required new Python cycle, Gate duration below 900 seconds, an appended maturity wait, missing Rust-self data classes, and forged immutable evidence.
• Preserve existing real-segment uploader, OSS triplet, health, process identity, resource, rotation, and cutover dry-run tests.
• Validate the merged exact source by building a signed artifact, running a real closed-segment preflight, executing the 900-second ECS Gate, independently reading evidence back, cutting over, and checking procfs binary hashes.
• CI tests should prove release-critical path selection and that non-release lanes report independently without changing deployment semantics.

Out of Scope

Research or snapshot logic, evaluator/MCTS, issue #235, exchange strategy behavior,
new collector features, overwriting immutable releases, or broad repository cleanup.

Further Notes

The production controller is /root. Gate failure stops Rust shadow and retains
Python. Runtime and tracking issues close only after live target, identity,
rollback, stop-rule, result, and cleanup evidence are recorded.