Summary
The staging drift workflow currently relies on git ancestry/cherry behavior that expects production release commits from main to become ancestors of staging. The repo's PR settings disallow merge commits and use squash merges, so an ancestry-only main-to-staging sync PR cannot be merged.
Why this matters
After production release 0.18.0, PR #777 synced the release content back into staging and staging deployed successfully, but git cherry still reported the main release commit because the squash merge did not preserve ancestry. A follow-up ancestry-only PR #778 could not be merged because GitHub rejected merge commits for this repository.
Desired outcome
Update the workflow/process so drift detection and cleanup work correctly under the repository's squash-only PR policy.
Acceptance criteria
- Drift detection no longer reopens or reports already-synced release content solely because ancestry was not preserved.
- The documented main-to-staging reconciliation process matches what the repository branch/merge settings actually allow.
- docs/release-flow.md and AGENTS.md are updated if the process changes.
- Any workflow/script tests are updated to cover the squash-only behavior.
References
Summary
The staging drift workflow currently relies on git ancestry/cherry behavior that expects production release commits from main to become ancestors of staging. The repo's PR settings disallow merge commits and use squash merges, so an ancestry-only main-to-staging sync PR cannot be merged.
Why this matters
After production release 0.18.0, PR #777 synced the release content back into staging and staging deployed successfully, but git cherry still reported the main release commit because the squash merge did not preserve ancestry. A follow-up ancestry-only PR #778 could not be merged because GitHub rejected merge commits for this repository.
Desired outcome
Update the workflow/process so drift detection and cleanup work correctly under the repository's squash-only PR policy.
Acceptance criteria
References