[HTExplicit]

Summary

Add a rollback-preserve operation to Production Deploy. It rolls production back to an older immutable release while keeping the running runtime flags and resource profile. Until now a rollback required restating every Cindy flag explicitly, which is error-prone in an emergency.

• rollback-preserve maps to OPERATION=rollback with runtime preserve. The run name reads Rollback to <tag> (preserve). It still requires confirmation=ROLLBACK, expected_current_release_tag, a strictly older target and resource=preserve, and it cannot interrupt business traffic.
• The host command is rollback <IMAGE> from=<CURRENT> runtime=preserve. The existing host updater already handles runtime=preserve rollback-from=…:
  • it keeps the running flags and backs up first;
  • it refuses unless both releases share the same data contract;
  • it never restores a database snapshot in preserve mode.
• The host entry wrapper (/usr/local/sbin/sub2api-deploy-command, maintained outside this repository) gains the matching command form. It is installed through the guarded deploy-maintenance entry. Until it is installed, this operation is rejected on the host with no change.

Validation

• Extracted the deploy step's command construction and replayed it:
  • rollback + preserve → rollback <OLD> from=<NEW> runtime=preserve;
  • explicit rollback and preserve deploy are unchanged;
  • reconcile + preserve and rollback + resource=auto are rejected.
• Workflow YAML parses; the operation options now include rollback-preserve.
• Host wrapper sandbox, with a stub updater and the real shared library:
  • preserve rollback passes <OLD> runtime=preserve rollback-from=<NEW>;
  • a resource profile, or a non-downgrade, is rejected;
  • existing commands are unchanged.

🤖 Generated with Claude Code

[HTExplicit]

Superseded by merged PR #202, which includes preserve-mode rollback without changing runtime configuration. Existing data compatibility constraints and the native-to-legacy host boundary still apply.