[HTExplicit]

Summary

Two release-path guards the user asked for after the v0.2.7-codexrip.3 outage and the recurring false deploy failures.

• Refuse reused bundled plugin versions (downstream-release.yml, verify job). Before anything is built, the release compares each plugins/*/manifest.source.json version with the previous v*-codexrip.* tag on the same history. It fails if any plugin kept its version. Every release re-signs the bundled packages, and an installed immutable version cannot take different bytes. That is exactly how .3 left the plugin manager degraded and every gateway request returning 503. A plugin added since the previous release is skipped; any other error fails closed.
• Wait for deploy readiness (production-deploy.yml). The public health step retries for up to three minutes: 36 retries at a 5 s delay, capped by --retry-max-time 180, and it also retries on connection refused. Before, it made four attempts in about six seconds. Every recent deploy applied correctly but logged four 502s while the container was still running migrations and plugin bootstrap, so the workflow was marked failed.

Validation

• Replayed the plugin check against real tags, using a local Python reader in place of jq:
  • v0.2.7-codexrip.3 vs .2 → FAIL (all seven plugins still at 0.2.8);
  • .2 vs .1 → pass;
  • .4 vs .3 → pass;
  • v0.2.8-codexrip.1 vs .4 → pass.
• Both workflow files parse as YAML.

Merge after v0.2.8-codexrip.2 is deployed, so the in-flight diagnostics release is not re-queued.

🤖 Generated with Claude Code

[HTExplicit]

Superseded by merged PR #202. Deploy-readiness retries are included in the native host workflow. First-party plugin version checks retire with the separate plugin packaging chain.