npm publishフローを@candidate直行へ変更、@staging廃止 - #14
Conversation
terra 2回のレビューサイクルを経て確定。設計根拠・経緯: magi-system側 .codex-review/npm_publish_flow_redesign_design.md 背景: Web/Server側はREVISIONで頻繁にstagingへ更新し続けるが、npm publishは 一度実行すると凍結される構造的ミスマッチがあり、@stagingへpublishされた 0.36.0が@candidateへの昇格を一度も試みられないまま放置される事故を招いた。 変更内容: - npm-package.yml: ブランチ条件をstaging→mainへ、publish先を --tag staging→--tag candidateへ変更 - head_sha検証を追加: dispatch元runのhead_shaがMagi-Systemのmain先端と 完全一致することを要求(古い成果物・stale runの再利用防止) - candidateダウングレード防止チェックを新規ステップとして移植 (旧promote-staging-to-candidate.ymlのロジック+semver厳格検証を追加) - 判定ロジックをscripts/npm-publish-policy.mjsへ抽出しユニットテスト化 (18件)、YAML契約テスト(6件)も追加してscripts/を実際に呼んでいることを検証 - promote-staging-to-candidate.yml・rollback-staging.ymlを削除 - remove-staging-tag.yml(ワンオフ): @stagingタグ削除用、実行後に別PRで削除予定 既知の制約: Magi-Systemのmainブランチ保護(PR必須・CI必須)はGitHub有料プラン 限定のため未設定。head_sha検証は「最新性」の保証のみで「レビュー済み」の 保証ではない(terra指摘、ユーザー判断によりこの制約を受容)。 テスト: npm test 157件全pass(新規24件込み)。 Co-Authored-By: Claude Sonnet 5 <[email protected]>
1. verifyCandidateVersion: 既存@candidateと同一バージョンをeq許可(冪等) から明示拒否に変更。npm publishは同一versionを再publishできず 実運用と不整合だったため(terra指摘) 2. YAML契約テストに5件追加: - checkout/setup-nodeが両検証stepより前にあること - publishがcandidate検証stepより後にあること - verify-run呼び出しに--head-sha/--main-shaが渡ること - policy CLI呼び出しが || true 等で握りつぶされていないこと - set -eu が該当stepで有効なこと テスト: npm test 162件全pass(既存157件+5件)。 Co-Authored-By: Claude Sonnet 5 <[email protected]>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: aa2847e7bc
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }} | ||
| run: | | ||
| set -eu | ||
| CURRENT=$(npm view "@bash0816/magi-server" dist-tags.staging 2>/dev/null || true) |
There was a problem hiding this comment.
If the npm registry is temporarily unavailable or rejects the request, npm view exits nonzero with empty stdout, but 2>/dev/null || true converts that failure into an empty CURRENT; the workflow then reports that the tag is already absent and exits successfully without removing it. The inspected npm view --help describes this command as “View registry info,” and a forced failed lookup returned exit code 1 with empty stdout, so only a successful lookup with no value should take the no-op path—especially because this one-off workflow is intended to be deleted after a green run.
Useful? React with 👍 / 👎.
1 participant
背景
Web/Server側（
Magi-System）はREVISIONで頻繁にstagingへ更新し続けるが、npm publishは一度実行すると内容が凍結される（同一バージョンの再publish不可）。「@staging」という中間npmタグは「検証中の最新」を表すつもりだったが、実態としてはpublish後にrevisionが進んでも自動追随せず置き去りにされる構造的ミスマッチがあった。0.36.0は2026-08-22に@stagingへpublish成功していたが、@candidateへの昇格が一度も試みられないまま次バージョン(0.36.1)の作業へ進んでしまい放置された（gh run listで確認: 最終promote実行2026-08-13 < 0.36.0 publish 2026-08-22）。変更内容
npm-package.yml: ブランチ条件をstaging→main、publish先を--tag staging→--tag candidateへ変更head_sha検証を追加: dispatch元runのhead_shaがMagi-Systemのmain先端と完全一致することを要求（stale run再利用防止）@candidateダウングレード防止チェックを新規ステップとして移植（旧promote-staging-to-candidate.ymlのロジック）+ semver厳格検証（prerelease拒否）+ 同一バージョンの明示拒否（npm publishの実運用と整合）scripts/npm-publish-policy.mjsへ抽出しユニットテスト化（29件）、scripts/npm-publish-policy-cli.mjs経由でYAMLから呼び出す構成にpromote-staging-to-candidate.yml・rollback-staging.ymlを削除（@staging廃止に伴い不要）remove-staging-tag.yml（ワンオフ）を追加:@stagingタグ（0.36.0を指したまま凍結）を削除するため。実行後に別PRで削除予定決定事項（ユーザー確定）
0.36.0は本来公開すべきではなかったバージョンであり、新フローに一切紐付けない0.35.2の次が0.36.1（0.36.0は欠番）@stagingnpmタグは即時削除（remove-staging-tag.ymlで対応）既知の制約（受容済み）
Magi-SystemのmainブランチはGitHub側のブランチ保護機能が有料プラン限定のため未設定（プライベートリポジトリ+GitHub Free/Team枠、gh api .../branches/main/protectionで403確認済み）。ローカルのpre-push hookによる直接push抑止のみが保護手段。head_sha検証は「最新性」の保証にしかならず「レビュー済み・正当な変更」の技術的保証ではない。詳細はMagi-System側docs/npm-release-runbook.md参照。レビュー経緯
STEP2設計レビュー（terra、No-Go→対応方針確定）→STEP3実装プランレビュー（terra、Conditional Go・4Blocker）→全条件対応→STEP8コーディングレビュー1回目（terra、Conditional Go・2件）→対応→STEP8コーディングレビュー2回目（terra、Go）。
テスト
npm test: 162件全pass（既存133件+新規29件）設計文書全文: Magi-System側
.codex-review/npm_publish_flow_redesign_design.md🤖 Generated with Claude Code