chore(release): open dev at 2.50.0 before releasing 2.49.0

[github-actions]

Summary

2.49.0 is about to be released. Merging this first means dev already outranks the new tag when it lands, so neither dev nor any open pull request ever inherits the version-line failure. release.yml refuses to publish until this has merged.

This moves dev to 2.50.0.

Opened automatically by .github/workflows/dev-version-bump.yml. The same
version-line move was previously done by hand in 32529c2, e4a85d1, 076ad30, and
befcac3.

Verification

The workflow proved 2.49.0 has neither a Git tag nor an npm publication, and bun test tests/ci-workflows/release-version-line.test.ts proved the chosen development version is unused.

Checklist

• Scope stays focused and avoids unrelated cleanup.
• Docs or release notes were updated when needed.
• Security-sensitive changes were reviewed for secrets, auth, and unsafe defaults.

[lidge-jun]

Maintainer integration for the authorized 2.49.0 release. The exact head f92f4f4 changes only package.json version from 2.49.0 to 2.50.0 above audited dev ad36c7b. Dev-version-bump run 34350749404 passed its unused-version checks and all three release-version-line tests after writing 2.50.0. Product source is unchanged from the 26/26 full CI and 3/3 service-verified baseline. This is version-only proof, not a claim of a new full matrix on this commit. Local product execution was NOT RUN. The release product baseline remains ad36; no 2.50 package is being published.

[lidge-jun]

리뷰 · 우선순위 78 / 80

이 PR은 제품 기능을 고치는 게 아니라, 지금 dev에 적혀 있는 버전 숫자만 올리는 릴리스 준비 작업입니다. 현재 dev HEAD(ad36c7be8, #4113 포함)의 package.json은 아직 2.49.0입니다. 안정판 2.49.0을 main에서 찍으려면 .github/workflows/release.yml의 “Require dev to be ready for this release” 단계가 origin/dev 버전이 앞으로 찍을 태그보다 엄격히 앞이어야 한다고 검사합니다. 지금처럼 dev도 2.49.0이면 “앞선다”를 통과하지 못해 안정판 배포 디스패치가 거절됩니다.

게다가 tests/ci-workflows/release-version-line.test.ts는 이미 찍힌 태그보다 트리 버전이 뒤처지면 빨갛게 만듭니다. 안정판 2.49.0이 한 번 나가면 dev와 그 위를 향한 모든 PR이 자기 디프와 무관한 버전 라인 실패를 물려받게 됩니다. 그래서 이 PR이 package.json의 "version"만 2.49.0에서 2.50.0으로 올립니다. 숫자는 손으로 고른 게 아니라 scripts/bump-dev-version.ts / nextDevelopmentVersion 규칙입니다. 안정판 X.Y.Z가 나가면 dev는 X.(Y+1).0으로 갑니다. 2.49.0이면 2.50.0이 맞습니다.

열림 경로는 .github/workflows/dev-version-bump.yml의 pre-move 모드입니다. 워크플로가 v2.49.0 태그와 npm @bitkyc08/opencodex@2.49.0이 아직 없다고 확인한 뒤 PR을 열었고, 같은 검증을 이 리뷰 시점에도 다시 보면 태그·npm 모두 아직 없습니다. release.yml은 이 이동이 dev에 합쳐질 때까지 게시를 거절합니다. 봇이 dev에 직접 푸시하지 않고 PR만 연 것도 맞습니다. ruleset Protect dev는 승인 리뷰와 코드오너 서명이 필요합니다. 디프는 진짜로 package.json 한 줄뿐이고, types/config 대형 분리 캠페인과도 무관합니다. 이전에도 같은 패턴이 #4019(2.49.0 오픈), #3925(2.48.0 오픈)로 반복됐습니다.

라인 3 (package.json) - 2.49.0 → 2.50.0 한 줄 변경. bump-dev-version.ts의 안정판→다음 마이너 규칙과 일치하고, 제품 코드·워크플로 파일은 건드리지 않았습니다.
scripts/bump-dev-version.ts / nextDevelopmentVersion - 안정판 입력에 대한 후보가 2.50.0인지 이 PR 범위에서는 서술·워크플로 검증에 맡기고, 호스티드 CI의 release-version-line 스위트가 최종 확인을 맡습니다.
.github/workflows/release.yml 게이트 - 이 PR만으로는 게이트를 통과시킨 것이 아닙니다. dev에 머지된 뒤에야 “Require dev to be ready for this release”가 2.50.0 vs 찍으려는 2.49.0을 통과합니다.
호스티드 CI - 이 헤드(codex/dev-version-2.50.0)에는 아직 체크가 보고되지 않았습니다. 버전 한 줄이라 실패 여지는 작지만, 초록을 확인한 뒤 합치는 편이 안전합니다.

메인테이너의 판단이 필요한 지점

• 안정판 2.49.0을 지금 바로 찍을 준비가 main/preview에 되어 있는지, 이 PR을 먼저 합친 직후 디스패치할지
• 호스티드 CI가 아직 없다면 CI 초록을 기다릴지, 버전 한 줄·규칙 일치만으로 바로 합칠지
• 합친 뒤 opencodex-dev-state.json의 packageVersion을 2.50.0으로 갱신하고, 안정판 태그 작업으로 바로 넘어갈지

너의 추천
지금 dev 방향(#4113 조성 툴 스키마 보존 등 2.49.x 마무리)과 충돌하지 않는 릴리스 하이진이라서 바로 머지하는 게 맞습니다. 머지 직후 안정판 2.49.0 디스패치를 이어가면, dev/열린 PR이 버전 라인 빨강을 물려받는 창을 거의 만들지 않습니다. CI가 곧 초록이면 추가 수정 없이 합치면 됩니다. types/config 분리와 무관하니 닫지 말고 살려 두세요.

이 댓글은 grok-bot이 작성했습니다