Fail Polymarket Gate before cutover target drift

[proerror77]

Change contract

Fail the Polymarket shadow Gate before its observation clock when the production cutover target already contains control or systemd state that the promotion path would reject, and repeat the same read-only check before transition.

Out of scope

Collector behavior, Gate duration, PID or immutable evidence semantics, snapshot or research logic, and issue #235.

Dependency or merge order

None.

Focused validation

• bash deployment/aliyun/test-polymarket-raw-ops-control-plane.sh
• bash -n on the Gate, cutover, and control-plane test scripts
• shellcheck on the same three scripts
• git diff --check
• Counterexamples cover unsafe, empty, and incomplete global control state; canonical unit fragments and all five production DropInPaths; stale Rust state in legacy mode; release-specific Rust-to-Rust control membership; cleanup failure propagation; and rollback metadata rejection before mutation.
• Dual-axis code review: no P0-P2 findings.

Rollout / rollback impact

Future release bundles fail before the 4201-second observation if the target is already unsafe, then recheck immediately before transition. The currently running immutable #326 candidate is unchanged. Roll back by reverting this PR.

A PRD is unnecessary because this is a small, already-specified deployment-order defect with one behavior contract.

Closes #403

Summary by CodeRabbit

• Bug Fixes

  • Strengthened deployment cutover checks for baseline modes, service configuration, permissions, control assets, and release manifests.
  • Added validation to ensure only properly verified control-plane releases and expected binaries are accepted.
  • Prevented cutover transitions when required preflight checks fail.

• Tests

  • Expanded coverage for valid and invalid legacy and Rust deployment scenarios.
  • Added checks for missing, stale, incomplete, or unauthorized control files.
  • Verified preflight checks run before service observation and cutover transitions.

[coderabbitai]

📝 Walkthrough

Walkthrough

Cutover and shadow-gate scripts now share fail-closed preflight checks for baseline mode, active binaries, systemd drop-ins, control-directory trust, bundled assets, and release manifests. Tests verify release binding, contract consistency, ordering, and legacy/Rust baseline scenarios.

Changes

Cutover control validation

Layer / File(s)	Summary
Control release verification deployment/aliyun/polymarket-raw-ops-shadow-gate.sh	Adds control-directory and release-manifest verification tied to the expected binary and SHA.
Cutover target preflight deployment/aliyun/polymarket-raw-ops-cutover.sh, deployment/aliyun/polymarket-raw-ops-shadow-gate.sh	Validates cutover eligibility and invokes the checks before promotion or cutover proceeds.
Preflight and release verification tests deployment/aliyun/test-polymarket-raw-ops-control-plane.sh	Adds fixture assets, release-control rejection cases, contract consistency and ordering checks, and baseline simulations.

Estimated code review effort: 4 (Complex) | ~45 minutes

Possibly related issues

• Fail Polymarket shadow Gate before observation when cutover target has control or systemd drift #403 — Directly concerns fail-closed control-directory and systemd-drift checks before shadow observation and cutover.

Possibly related PRs

• proerror77/monday#34 — Introduced the Rust-based raw-ops control-plane rollout that these gate, cutover, and test changes extend.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly matches the main change: adding a preflight failure before cutover target drift.
Description check	✅ Passed	The description covers the required contract, out of scope, validation, and rollout, but it is missing an explicit Scope exception section.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch codex/polymarket-cutover-preflight-403

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

deployment/aliyun/test-polymarket-raw-ops-control-plane.sh (1)

176-184: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Add a rejection case for an insecure/missing bundled asset.

Both cases here turn on the candidate SHA. Because verify_control_release drops the return status of its per-asset secure_control_file call (polymarket-raw-ops-shadow-gate.sh Line 224) and this harness overrides that helper with a non-dying predicate, removing fixture-control would still let the positive assertion at Line 176 pass. A case that deletes or symlinks $release_manifest_dir/fixture-control and expects rejection would pin the fix.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@deployment/aliyun/test-polymarket-raw-ops-control-plane.sh` around lines 176
- 184, The test harness lacks coverage for a missing or insecure bundled asset
because both existing assertions vary only the candidate SHA. Add a rejection
case that removes or symlinks "$release_manifest_dir/fixture-control", invokes
verify_control_release with the valid candidate SHA, and asserts failure; use
the existing fixture-control setup and harness cleanup conventions.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@deployment/aliyun/polymarket-raw-ops-shadow-gate.sh`:
- Around line 222-225: The verify_control_release asset and manifest checks must
propagate predicate failures instead of silently continuing. In
deployment/aliyun/polymarket-raw-ops-shadow-gate.sh:222-225, include asset in
the local declarations and return 1 when either secure_control_file call fails;
apply the identical corresponding change to verify_control_release in
deployment/aliyun/polymarket-raw-ops-cutover.sh. In
deployment/aliyun/test-polymarket-raw-ops-control-plane.sh:176-184, add a
rejection case that removes or symlinks release_manifest_dir/fixture-control to
verify dropped asset-check status is detected.

---

Nitpick comments:
In `@deployment/aliyun/test-polymarket-raw-ops-control-plane.sh`:
- Around line 176-184: The test harness lacks coverage for a missing or insecure
bundled asset because both existing assertions vary only the candidate SHA. Add
a rejection case that removes or symlinks
"$release_manifest_dir/fixture-control", invokes verify_control_release with the
valid candidate SHA, and asserts failure; use the existing fixture-control setup
and harness cleanup conventions.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 8921f2ec-667a-469b-aed2-cb4c936ced61

📥 Commits

Reviewing files that changed from the base of the PR and between 076d584 and 4b99e0a.

📒 Files selected for processing (3)

• deployment/aliyun/polymarket-raw-ops-cutover.sh
• deployment/aliyun/polymarket-raw-ops-shadow-gate.sh
• deployment/aliyun/test-polymarket-raw-ops-control-plane.sh

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4b99e0ac2f

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".