shipcheck

shipcheck

そのリリースは本当に公開されましたか？ 1 つのコマンドで、すべての公開先を確認し、1 つの判定を出します。

現在のリリースは多くの公開先に関わります。git タグ、GitHub リリース、リポジトリ内のパッケージメタデータ、npm または PyPI、MCP Registry、そして GHCR 上のコンテナイメージです。ほかが正常に見えていても、そのうちの 1 つだけが何も知らせずに失敗することがあります。公開ワークフローは成功になっているのに、npm ではバージョンがステージング保留のまま、レジストリは前回のリリースを指したまま、コンテナタグがプッシュされていない、あるいは最悪の場合、git タグが存在しないコミットを指していることがあります。

shipcheck は、想定される 1 つのバージョンとすべての公開先を照合し、単一の判定を出力します。不一致の公開先と、それぞれの根拠を正確に示した GO または NO-GO です。両方のエコシステムに対応しています。Node リポジトリでは package.json と npm を、Python リポジトリでは pyproject.toml／setup.cfg／setup.py と PyPI を確認します。ハイブリッドリポジトリ（wallcheck のような、npm ラッパーを備えた Python コア）は、実際に存在するすべての配布先を確認します。

このツールが生まれた理由

shipcheck は抽象的な発想から設計されたものではありません。Greenlight とその関連ツールを公開する際に行っていた、手作業による確認作業をツールにしたものです。その確認作業では、実際に次のような問題を発見しました。

• git タグが存在しないコミットオブジェクトを指していたリリースがありました。npm、レジストリ、ソースはすべて実在していましたが、タグが実在するコミットを解決できることを確認して、初めて問題が見つかりました。そのため、tag-commit は必須チェックです。
• npm のステージング公開保留では、新しいパッケージバージョンが審査中のままになり、レジストリにはプレースホルダーしか表示されないことがあります。ユーザーから見ると、リリースは存在しないのと同じです。そのため、npm-version と npm-latest は別々のチェックになっています。
• npm での確認前にレジストリへの公開が開始され、MCP Registry がまだ npm に存在しないバージョンを指していたことがありました。この順序に関する教訓から、shipcheck はすべての公開先で「登録済み」と「最新」を異なる事実として扱います。

検証項目

対象	検証内容
git-tag	リポジトリにタグ v<version> が存在すること
tag-commit	タグが実際のコミットオブジェクトを指していること
tag-version	タグ時点の package.json に想定バージョンが記載されていること
pyproject-version	タグ時点のすべての Python バージョン情報が一致すること：pyproject.toml（[project] または [tool.poetry]）、setup.cfg、setup.py、および参照先ファイルから解決される動的バージョン（hatch、setuptools の attr: / file:、__version__）
server-version	タグ時点の server.json、そのパッケージバージョン、OCI タグがすべて一致すること
github-release	タグに対応する公開済み（ドラフトではない）GitHub リリースが存在すること
npm-version	npm パッケージにこのバージョンが公開されていること（リポジトリに npm パッケージがある場合のみ）
npm-latest	npm の dist-tags.latest がこのバージョンを指していること
pypi-version	PyPI パッケージにファイル付きでこのバージョンが公開されていること（Python プロジェクト）
pypi-latest	最新の PyPI リリースがこのバージョンであること
registry-version	MCP Registry にサーバーのこのバージョンが掲載されていること
registry-latest	MCP Registry でこのバージョンが最新かつアクティブとして指定されていること
ghcr-tag	GHCR イメージにこのバージョンのタグがあること
ghcr-latest	GHCR イメージに latest タグもあること
python-tests	ソフトチェック：タグに Python テストファイルがあり、テストランナーの形式（pytest の設定、または unittest の形式）に沿っていること
dockerfile	ソフトチェック：タグのツリーに Dockerfile があること
readme	ソフトチェック：リポジトリのルートに README があること
mcp-entry	ソフトチェック：MCP サーバーのエントリーポイント（*-mcp またはサーバーのコンソールスクリプト、あるいは server.json）があること

判定ルール：

• GO：すべての必須チェックに合格しています。終了コードは 0 です。
• NO-GO：必須チェックのいずれかが失敗またはエラーになっています。終了コードは 1 で、CI でそのまま利用できます。
• SKIP：該当しない対象は失敗ではなくスキップされます。MCP Registry のエントリーがないリポジトリでは Registry チェックがスキップされ、公開コンテナーイメージがないリポジトリでは GHCR がスキップされ、PyPI に公開されていない Python プロジェクトでは PyPI チェックがスキップされ、package.json がない Python プロジェクトでは npm チェックが失敗ではなくスキップされます。GHCR チェックはデフォルトではソフトチェックで、--require ghcr を指定すると必須チェックになります。
• 各チェックでは、想定値と実際の値、および取得元の URL が報告されます。取得に失敗した場合は、HTTP ステータスとともにエラーとして報告され、推測で補われることはありません。
• レポートには検出されたエコシステム（node、python、hybrid、unknown）が記載されます。メタデータの情報源がまったくない Python アプリ（requirements ファイルとソースのみ）でも、タグのツリーから検出されます。また、バージョン情報の欠落は、何も報告されずに合格扱いになるのではなく、根拠とともに SKIP として報告されます。

使い方

CLI

# Full check. Version is read from package.json or the Python metadata
# (pyproject.toml, setup.cfg, setup.py) on the default branch.
npx @reneturcios/shipcheck check CloudCorpRecords/greenlight

# Python and hybrid repos work the same way
npx @reneturcios/shipcheck check CloudCorpRecords/wallcheck 0.5.0

# Check a specific version
npx @reneturcios/shipcheck check CloudCorpRecords/greenlight 0.15.1

# Machine readable output, custom surface names, force GHCR to be required
npx @reneturcios/shipcheck check owner/repo 1.2.0 --json \
  --npm @scope/pkg --pypi pkg --server io.github.Owner/repo --require ghcr

# Single surfaces
npx @reneturcios/shipcheck npm @reneturcios/greenlight 0.15.1
npx @reneturcios/shipcheck pypi wallcheck 0.5.0
npx @reneturcios/shipcheck registry io.github.CloudCorpRecords/greenlight 0.15.1

出力例：

shipcheck CloudCorpRecords/greenlight v0.15.1: GO
  [PASS] git-tag: Tag v0.15.1 exists (object type commit)
  [PASS] tag-commit: Tag resolves to real commit f52939005a0f
  [PASS] tag-version: package.json at v0.15.1 is version 0.15.1
  [PASS] github-release: GitHub release v0.15.1 is published
  [PASS] npm-version: @reneturcios/[email protected] is published on npm
  [PASS] npm-latest: npm latest points at 0.15.1
  [PASS] registry-version: MCP Registry lists io.github.CloudCorpRecords/greenlight 0.15.1 (status active)
  [PASS] registry-latest: MCP Registry latest is 0.15.1 and active
  [PASS] ghcr-tag: GHCR image has tag 0.15.1
  [PASS] ghcr-latest: GHCR image has a latest tag
GO: every hard surface agrees on this version.

一般的なケースでは引数を 1 つだけ指定すればよいよう、推論が行われます。npm パッケージ名はタグまたはデフォルトブランチの package.json から、PyPI パッケージ名は Python メタデータから、Registry サーバー名は server.json がある場合はそこから（ない場合は io.github.<Owner>/<repo>）、GHCR イメージは ghcr.io/<owner>/<repo>（小文字）から取得されます。--npm、--pypi、--server、--ghcr でそれぞれ上書きできます。--skip npm,pypi,python,server,registry,ghcr,release,github でグループ全体をスキップできます。

GitHub API の認証済みレート制限を引き上げるには、GITHUB_TOKEN を設定してください。公開対象の確認にほかの認証情報は必要ありません。GHCR は、公開イメージに対して標準の匿名トークンフローを使用します。

MCP サーバー

MCP クライアントの設定に追加します：

{
  "mcpServers": {
    "shipcheck": {
      "command": "npx",
      "args": ["-y", "@reneturcios/shipcheck", "mcp"]
    }
  }
}

ツール：

• check_release：完全なチェックです。リポジトリ、任意のバージョン、任意の npm／PyPI／サーバーの上書き値、必須リストとスキップリストを指定します。
• check_npm：1 つの npm パッケージとバージョンを確認します。公開済みであることと、最新バージョンがそのバージョンを指していることを検証します。
• check_pypi：1 つの PyPI パッケージとバージョンを確認します。ファイル付きで公開済みであり、最新リリースであることを検証します。PyPI に存在しない場合は、スキップとして報告されます。
• check_registry：1 つの MCP Registry サーバーとバージョンを確認します。掲載済みであり、最新として指定されていることを検証します。

Docker

docker run -i ghcr.io/cloudcorprecords/shipcheck mcp
docker run --rm ghcr.io/cloudcorprecords/shipcheck check CloudCorpRecords/greenlight 0.15.1

ツールキット

shipcheck は、同じ作者による小規模で単一用途の開発者ツール群として計画されている Wave 1 のパッケージ 1 です。すべて同じ方法で構築されています。CLI と MCP サーバーを提供する 1 つの bin、根拠を伴う決定論的なチェック、そして回答を捏造しない設計です。

• greenlight：オープンソースへの貢献に向けた事前チェック。この issue は本当に取り込める状態ですか？
• prwatch：オープン中の PR の注目度レポート。今すぐ対応が必要なのはどれですか？
• claimcheck：フォーク上の古い主張の状態と、保留中の修正。
• gatefile：隠れた貢献条件を抽出し、機械可読な contribution-gates.json にします。
• pkgverdict：npm パッケージのインストール前判定。GO、RISKY、FAKE、または MISSING。

開発

npm install
npm run build
npm test   # 40 tests, all surface logic runs on injected fixtures, no network

ライセンス

MIT