You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
/release-sync v2.2.0 (step 9 of the v2.2.0 release flow per #452) — open the main→dev sync PR that makes the v2.2.0 squash commit an ancestor of dev, so the next dev→main release PR only sees genuinely-new commits instead of fighting squash-divergence (v2.0.0 hit 99 conflicts; v2.2.0 itself hit 14).
This is also the first real-world run of PR #451's CHANGELOG carry-forward (step 5b of /release-sync). The skill is now exercised end-to-end against production state.
Scope
Branch chore/GH-403-sync-after-v2.2.0 from upstream/dev (done)
git merge --no-ff -X ours upstream/main (done — dev wins on conflicts)
Open this sync PR — this ticket exists to track that step
Rex review + CEO /approve-merge + merge
Acceptance Criteria
Sync PR opens against dev from chore/GH-403-sync-after-v2.2.0
After merge: git log upstream/dev..upstream/main --oneline returns empty
After merge: dev's CHANGELOG.md top entry is ## [2.2.0] — 2026-05-29
After merge: git log upstream/main..upstream/dev --oneline shows only post-v2.2.0 commits
Risks / Dependencies
Risk: /release-sync skill spec deviates from validators — the spec prescribes sync: commit type, sync(...) PR title, and sync/ branch prefix, but none of those are on the framework's whitelists. The merge commit slipped through (git merge -m bypasses the bash hook), but the carry-forward commit, PR title, and branch name all had to be retitled to chore. Filing a separate follow-up to update the spec.
Glossary
Term
Definition
/release-sync
Skill that syncs main→dev after each release. Step 9 of /release. Introduced in v2.1.0 (#403).
CHANGELOG carry-forward (step 5b)
New step in /release-sync from PR #451 (#448) — restores main's CHANGELOG.md on dev after the -X ours merge correctly preserves dev's code but leaves CHANGELOG stale.
Squash divergence
The SHA gap created when a release PR is squash-merged: main has one squash commit; dev still carries the un-squashed equivalents.
Driver
/release-sync v2.2.0(step 9 of the v2.2.0 release flow per #452) — open the main→dev sync PR that makes the v2.2.0 squash commit an ancestor ofdev, so the nextdev→mainrelease PR only sees genuinely-new commits instead of fighting squash-divergence (v2.0.0 hit 99 conflicts; v2.2.0 itself hit 14).This is also the first real-world run of PR #451's CHANGELOG carry-forward (step 5b of
/release-sync). The skill is now exercised end-to-end against production state.Scope
chore/GH-403-sync-after-v2.2.0fromupstream/dev(done)git merge --no-ff -X ours upstream/main(done — dev wins on conflicts)git checkout upstream/main -- CHANGELOG.md+ atomic commit (done — first real-world feat(#448): /release-sync carry forward CHANGELOG.md from main to dev #451 run)/approve-merge+ mergeAcceptance Criteria
devfromchore/GH-403-sync-after-v2.2.0git log upstream/dev..upstream/main --onelinereturns emptyCHANGELOG.mdtop entry is## [2.2.0] — 2026-05-29git log upstream/main..upstream/dev --onelineshows only post-v2.2.0 commitsRisks / Dependencies
/release-syncskill spec deviates from validators — the spec prescribessync:commit type,sync(...)PR title, andsync/branch prefix, but none of those are on the framework's whitelists. The merge commit slipped through (git merge -mbypasses the bash hook), but the carry-forward commit, PR title, and branch name all had to be retitled tochore. Filing a separate follow-up to update the spec.Glossary
/release-sync/release. Introduced in v2.1.0 (#403)./release-syncfrom PR #451 (#448) — restores main'sCHANGELOG.mdon dev after the-X oursmerge correctly preserves dev's code but leaves CHANGELOG stale.