リリース

リリース

初回リリースでは、@alneas/[email protected]と@alneas/[email protected]のみを公開しました。機能はインポートのサブパスであり、個別のnpmパッケージではありません。内部の本番用依存関係には、レジストリ上の厳密なバージョンを使用します。公開済みのバージョンは変更できません。作業ツリー内のドキュメントやツールの変更は、後続のリリースに含めます。

ソースとアーカイブの同一性

今後のリリースでは、レビュー済みの変更をコミットし、そのコミットを厳密に指定して検証と公開を行ってください。選択したソースとアーカイブの整合性を記録し、公開後にnpm view <package>@<version> dist.integrityをレビュー済みのアーカイブと比較してください。既存のタグは、元のソースのスナップショットを識別します。後から加えた変更を含めるためにタグを移動しないでください。バージョン番号やタグが一致するだけで、アーカイブが同一だと判断しないでください。

確定したソースを選択してから、ビルド、型チェック、bun run check:release、bun run check:docsを実行してください。両方のパッケージをパックし、エクスポート、README、MITライセンス、ピア依存関係を確認したうえで、そのアーカイブ自体を使い捨ての利用側環境にインストールしてください。ネイティブESM、CommonJS、NodeNextの型宣言、React SSR、CSS、ドキュメントに記載されたフォームを確認してください。ブラウザーやアダプターの動作が変わる場合は、影響を受ける検証を実行してください。無関係な連携については、変更のない検証証跡を再利用してください。

過去の個別パッケージ形式のアーカイブでは、新しい境界を検証できません。ソースのハッシュ、アーカイブのダイジェスト、コマンドの実行結果を、バージョン管理の対象外となる検証記録に保存してください。保持した成果物を再利用できるのは、関連するソースとアーカイブのハッシュが引き続き一致する場合だけです。ビルドしていないソースを公開したり、検証後に成果物を変更したりしないでください。

新しいnpmパッケージの初回公開

このリポジトリのpublish.ymlは、既存のnpm パッケージの後続バージョン向けです。まだ一度も公開されていないパッケージ名の初期公開には対応していません。 ドキュメントに記載されたnpm Trusted Publisherの設定 は、そのパッケージのnpm設定で行います。まず、明示的な承認を受けたメンテナーが対話形式で 初回公開を行い、パッケージを作成してからOIDCを設定してください。 このワークフローで、存在しないパッケージを初期公開するためにGitHub Releaseを使わないでください。 GitHub Actionsではほかの認証方式も利用できますが、このリポジトリには トークン方式や手動ディスパッチによる公開の代替手段はありません。

新規パッケージの場合は、次の手順に従ってください。

1. 公開を承認する前に、初回の正確なアーカイブとバージョンをレビューし、検証してください。 新しいReactパッケージが初回のCoreパッケージに依存する場合は、Coreを先に公開してください。 レジストリに既存のバージョンがあることを必要とする検証は、初回公開後に適用されます。 そのバージョンが存在する前に、検証済みと表現してはいけません。
2. メンテナーがnpm loginでサインインし、レビュー済みアーカイブについて承認された対話形式の 公開を、2FA、公開アクセス、ライフサイクルスクリプト無効の設定で完了します。 1.0.0未満ではbetaで公開し、同じバージョンにlatestを追加して、 両方のマッピングを読み戻します。1.0.0以上ではlatestを必須とします。レジストリの アーカイブの完全性を、レビュー済みアーカイブと照合してください。この手順はnpmへの書き込みを伴い、 PRの準備やマージの一環として自動実行されることはありません。
3. パッケージが存在するようになったら、Trusted Publishingを設定します。dataarthub/appkit、 publish.yml、対応する任意の環境を指定し、ステージングを有効にして、Allow npm publishを無効、 Allow npm dist-tagを有効にします。初回のOIDCによる公開前に、設定の有効期限に関する要件も含め、 npmの最新の設定手順に従ってください。
4. 以降のバージョンは、以下のパッケージ別Release手順で公開してください。 Actionの動作確認や来歴情報の追加だけを目的として、初回公開バージョンを再公開してはいけません。

Appkitの両パッケージは、すでに0.1.0として存在しており、この初期公開は完了しています。 Actionsを使用した初回公開は、設定とワークフローのレビュー後の次のバージョンで実施できます。 既存の0.1.0のアーカイブとnpmタグは変更しないでください。

公開のセキュリティ

GitHub Actionsでnpm Trusted Publishingを使用してください。各パッケージのnpm設定で、GitHub所有者をdataarthub、リポジトリをappkit、ワークフローファイル名をpublish.ymlに設定し、環境を指定する場合はそれぞれnpm-coreまたはnpm-reactにします。Allow npm publishは無効、Allow npm dist-tagは有効のままにしてください。OIDCによるステージングは引き続き有効です。承認にはメンテナーのnpmセッションと2FAが必要です。これらの権限は互いに独立しています。OIDCによるdist-tag操作にはnpm 11.21.0+が必要であり、ワークフローではこのバージョンを固定しています。メンテナーに2FAを必須とし、パッケージ設定で2FAを必須にしてトークンを禁止してください。このポリシーでも、信頼された公開元は公開できます。これらはアカウント／パッケージの設定であり、リポジトリの編集では有効になりません。

publish.ymlワークフローには2つの開始方法があります。パッケージ別の安定版GitHub Releaseを公開すると、そのアーカイブを検証してステージに配置します。mainで手動ディスパッチすると、すでに承認済みのステージ済みリリースを完了します。GitHubホスト型ランナーで動作するレジストリジョブは、Node 24、バージョンを固定したnpm 11.21.0、id-token: writeを使用し、npm書き込みトークンは使用しません。ステージングコマンドは来歴情報を明示的に要求し、ライフサイクルスクリプトを無効にします。検証処理と再開対象の解決処理にはOIDC権限がありません。レジストリジョブはパッケージの開発依存関係をインストールしません。main更新時の品質検証ワークフローは、引き続き検証のみを行います。

この変更をマージした後、両方のパッケージのnpm Trusted Publisher設定を確認してください。リポジトリはdataarthub/appkit、ワークフローはpublish.yml、任意の環境は対応するものに設定し、直接公開を無効、dist-tagを許可にします。以前に直接公開を有効にしていた場合、このワークフローの変更で自動的に無効へ戻ることはありません。リポジトリの編集ではnpm設定は変わりません。環境名はnpm-coreとnpm-reactのままです。ステージングと完了処理ではdeployment: falseを使用し、承認待ちの状態が公開Deploymentの成功として表示されないようにします。カスタムのデプロイ保護ルールを使用する環境は、このGitHub設定と互換性がないため、採用前に確認が必要です。

既存の0.1.0リリースにはprovenanceの証明がありません。後から追加したワークフローで遡って証明することはできません。今後、provenanceによる証明を伴うリリースには、新しいバージョンを使用してください。GitHubのタグやReleaseとnpmへの公開は別のものです。ブランチやタグのプッシュを起点にnpmへの公開を実行したり、既存のバージョンを上書きしたりしてはいけません。途中まで完了した公開を再開する前に、レジストリ上の整合性を検証してください。

パッケージ別のReleaseを公開する

2つのパッケージでは、バージョン、タグ、GitHub Releaseをそれぞれ独立して管理します。

GitHubタグ	公開対象となる唯一のパッケージ	デプロイ環境
appkit-core-vX.Y.Z	@alneas/appkit-core	npm-core
appkit-react-vX.Y.Z	@alneas/appkit-react	npm-react

バージョンを変更する前に、リリースの範囲を選択してください。

範囲	バージョンと依存関係の変更	GitHub Release
Coreのみ	Coreのバージョンを上げます。Reactと、その厳密なCore依存バージョンは変更しません	CoreのReleaseを1つ公開します
Reactのみ	Reactのバージョンを上げます。公開済みのCoreを新たに採用する場合を除き、Coreの固定バージョンは維持します	ReactのReleaseを1つ公開します
両方を対象とし、Reactが新しいCoreを採用します	まずCoreのバージョンを上げて公開します。その後、後続のPRでReactのバージョンを上げ、Coreの固定バージョンを更新します	CoreのReleaseを公開した後、ReactのReleaseを公開します
両方を対象とし、Reactが公開済みのCoreの固定バージョンを維持します	必要に応じて各パッケージのバージョンを上げ、互換性ゲートを実行します	パッケージごとに1つ、合計2つのReleaseを公開します

元のv0.1.0は、引き続き初回の共有リリースタグです。このタグは新しい 公開処理を起動しません。ドラフトRelease、プレリリース、無関係なタグ、タグのプッシュ、 手動のワークフローディスパッチでは、このワークフローを通じて新しいパッケージがステージに配置されることはありません。 手動ディスパッチは、最初に成功したステージング実行の完了処理専用です。

1. 対象パッケージのバージョンと、関連するロックファイル／生成メタデータのみを更新してください。 Reactが新しいCoreを採用する場合は、まずそのCoreの公開を成功させてから、 後続のPRでReactの完全一致の依存バージョンとReact自身のバージョンを更新します。 レビュー済みの変更をコミットし、mainにマージしてください。
2. その正確なmainコミットのPublic qualityが成功するまで待ってください。 後続の未検証コミットにタグを付けたり、機能ブランチや手動の実行を代わりに使用したりしてはいけません。 その正確なレビュー済みコミットに、パッケージ固有のタグを作成します。タグ内のバージョンは、 選択したパッケージのpackage.jsonと一致する必要があります。もう一方のパッケージの バージョンは異なっていてもかまいません。ワークフローは、mainに含まれないコミットと、参照先が変更されたタグを拒否します。
3. そのタグのドラフトGitHub Releaseを準備してください。Releaseの公開によって 自動ステージングが承認されます。npmで一般公開するには、引き続き以下の別途のnpm 2FA承認が必要です。
4. Publish package releaseワークフローを確認してください。アーカイブの準備に入る前に、 このリポジトリ内のリリースと完全に同じSHAについて、.github/workflows/quality.yml （Public quality）のmain-push実行が完了し、成功していることが必要です。証跡が存在しない場合や、 キュー待ち、実行中、失敗、キャンセル、スキップの状態である場合は、公開がブロックされます。 同じSHAに対して、より新しい実行が成功していない場合、古い成功実行にフォールバックすることはできません。 mainの品質検証を完了／再実行してから、リリースワークフローを再試行してください。 ワークフローは無期限に待機したり、成功を見込んで公開を開始したりはしません。 ワークフローは、その正確なコミットのソース品質検証の証跡を再利用し、一致する Turboビルドキャッシュを復元して、シークレット、lint、ツール、ビルド、リリース／ドキュメントの 契約をチェックします。Public qualityですでに検証されたソースのユニットテスト／型チェック／エージェントスイートは 再実行しません。両方の候補をパッケージ化し、その正確なアーカイブを 分離した利用側環境でテストしてから、タグ付きパッケージのテスト済みアーカイブだけを選んでステージに配置します。
5. Reactのリリースでは、さらに2種類のCoreによる互換性マトリックスと、 必須修正の依存関係ポリシーを満たす必要があります。Coreのリリースは、Reactが 未公開の依存関係を採用するのを待ちません。連携した更新では、CoreのReleaseを公開し、 npmへの公開が成功するまで待ってから、ReactのReleaseを公開してください。

Storybookは、影響を受ける対象を選択したmainの品質検証（または明示的な 全体チェック／手動チェック）でのみ実行し、公開時には再実行しません。品質検証の選択では、 成功した祖先コミット以降の変更を累積するため、ドキュメントのみが変更された対象では、 変更のないUIテストを省略しても問題ありません。公開ジョブはリリース検証の成功に依存し、 npmの手順の直前に、完全に同じSHAの品質検証の証跡を再確認します。 証跡APIが利用できない場合も公開をブロックします。OIDC権限を持つのは、ステージングと完了処理の レジストリジョブだけです。これにより、ブラウザー検証を重複させずに、ソース検証、アーカイブ検証、 レジストリへの書き込みを順序どおりに実行します。GitHub Releaseの公開が この処理を開始します。Releaseページが存在するだけでは、npmへの公開が成功したことにはなりません。

検証済みアーカイブは、不変のアーティファクトID、SHA-512ダイジェスト、機密情報などを除去したソース／パッケージ識別マニフェストを通じてステージングに渡されます。アップロードするのはアーカイブと機密情報などを除去したマニフェストだけです。生の受領記録とログは引き続き含めません。ステージングでは、そのアーカイブを送信する前に、ソース、内容、ダイジェストを再確認します。最初のワークフローの成功は、ステージに配置されたことを意味し、一般公開されたことを意味しません。

ステージ済みリリースの承認と完了

1. npmでパッケージのStaged Packagesを開きます。名前、バージョン、ソース／来歴情報、最初の確認専用タグ（staged）を確認し、アーカイブをワークフロー概要のSHA-512ダイジェストと照合してください。認証済みのメンテナーは、npm stage list <package>、npm stage view <stage-id>、npm stage download <stage-id>を使用して内容を確認できます。これらの操作ではActionsのOIDCセッションを使用できません。想定外のステージを、バージョンが正しそうだという理由だけで承認してはいけません。
2. npmで2FAを使用してステージを承認するか、メンテナーの対話型セッションでnpm stage approve <stage-id>を使用します。Actionsがステージを承認することはありません。拒否にもメンテナーの2FAが必要です。npmのステージング公開を参照してください。
3. GitHub ActionsでPublish package release → Run workflow → mainを選択します。staged_runには、完了処理の実行IDではなく、元の成功したステージング実行の数値IDを設定します。このIDは実行のURLと概要に表示されます。リゾルバーは、publish.ymlの成功したReleaseイベント実行、その成功したステージングジョブ、およびその実行の現在の試行に対応する正確な不変アーカイブを必要とします。以前の直接公開の実行、フォーク、失敗した実行、有効期限切れのアーカイブは使用できません。
4. 完了処理では、元のRelease／タグ、mainの祖先関係、完全に同じSHAのPublic qualityを再確認し、元のアーカイブをダウンロードして、公開済みnpmバージョンの完全性をそのアーカイブと照合します。再公開せずに不足する必須タグを修復し、npmページのURLとともに、元のソースSHAに対するnpm-coreまたはnpm-reactのDeployment成功を記録します。再ビルドやテストの再実行は行いません。完了ワークフローが成功し、レジストリのバイト列／タグが確認され、Deploymentが成功すると、リリースは完了です。

承認後、レジストリでの表示やdist-tagの反映には時間がかかることがあります。完了処理は、表示確認／タグ確認の各段階で最大5分間待機します。未承認、ネットワークエラー、未確認のタグがある場合、リリースは未完了です。同じ元のステージング実行IDを使用して、手動の完了処理を再試行してください。アーカイブの完全性が一致しない場合や、必須タグがより新しいバージョンを指している場合は、安全側に停止します。どちらも上書きやロールバックをしてはいけません。

ステージングでバイト列の送信後にエラーやタイムアウトが発生した場合は、再試行する前にnpmのStaged Packagesを確認してください。そのバージョンは、すでに予約されている可能性があります。再アップロードのために、確認せずにすべてのジョブを再実行してはいけません。OIDCでは、ステージの一覧取得、内容確認、承認、拒否はできません。元のステージング実行が失敗した場合は、権限を持つメンテナーが2FAを使用して保留中のステージを解決または拒否してから、ステージングを再試行する必要があります。拒否されたからといって、異なるバイト列を再公開する権限が自動的に与えられるわけではありません。ワークフローは、結果が不明確なアップロードを成功として扱いません。

アーティファクトの保持期間は7日間です。その期間内に承認と完了処理を行ってください。有効期限が切れた場合は作業を停止し、メンテナーと復旧方法を検討してください。タグを移動したり、新たにビルドしたアーカイブを以前のものと主張したりせず、元のバイト列とステージの識別情報を復旧して再検証します。ワークフロー全体を再実行すると、異なるバイト列が生成される可能性があるため、一般的な修復手順としては使用できません。公開済みバージョンと成功済みのデプロイは、そのまま維持されます。

同時に実行されたステージング／完了ワークフローは直列化され、書き込みの途中ではキャンセルされません。連携するCoreとReactのリリースは、依存関係の順序で完了させてください。npmで承認すると、バージョンは確認専用タグのstagedで一般公開されます。承認によってbetaやlatestが移動することはありません。これらのチャネルを移動するのは、バージョンの順序を確認した後の完了処理だけです。そのため、古いステージを後から承認しても、通常の利用者向けチャネルがロールバックされることはありません。利用者にstagedを推奨してはいけません。承認済みでも、完了処理が保留中またはブロックされているバージョンを指す可能性があります。完了処理で両方の必須タグが確認されるまで、1.0未満のリリースは未完了です。

Reactが新しいCoreを採用する場合に両パッケージを公開する

たとえば、両パッケージを0.1.0から0.1.1に移行する場合は、次の手順に従います。

1. Core準備PR： Coreを0.1.1に設定し、Reactは0.1.0のまま、完全一致の Core依存バージョン0.1.0を維持して、ロックファイル／生成メタデータを更新します。修正を Reactにも適用する必要がある場合は、以下の例のようにcoreVersion: "0.1.1"と reactVersion: "0.1.1"を使用して要件を追加します。検証ゲートは、その採用が保留中であることを報告し、 引き続き両方の互換性検証レーンの成功を要求します。検証済みのPRをマージしてください。
2. そのレビュー済みmainコミットにappkit-core-v0.1.1を作成し、GitHub Releaseを公開します。2FAでnpmのステージを承認し、元の ステージング実行IDを使用して手動の完了処理を実行します。npmの完全性、必須dist-tag、 npm-coreのデプロイを含め、完了するまで待ってください。GitHub Releaseが公開されただけでは、npmへの公開が成功したことにはなりません。
3. React採用PR： Core 0.1.1がnpmに存在するようになったら、Reactを0.1.1に、 完全一致のCore依存バージョンを"0.1.1"に設定し、ロックファイル／生成メタデータを更新します。 要件エントリーは残してください。この時点ではReactのバージョンによる採用期限が適用されるため、古いCoreに 固定したままではCIが失敗します。両方のパッケージをビルドしてからbun run check:react-core --releaseを実行し、 検証済みのPRをマージしてください。
4. その後のmainコミットにappkit-react-v0.1.1タグを付け、GitHub Releaseを公開し、 2FAでnpmのステージを承認してから、手動で完了処理を行い、レジストリの 完全性、必須タグ、npm-reactのDeploymentを確認してください。

これは2つのReleaseであり、通常はソースコミットも2つに分かれます。1つのReleaseで 両方のパッケージを公開するわけではありません。先に作成したCoreタグをReactのコミットへ移動してはいけません。 Reactが公開済みCoreへの固定を維持し、両パッケージのバージョンを同時に確定した場合は、 両方のタグが同じmainコミットを指していてもかまいません。常に別々の Releaseを使用し、最初のリリースの完了処理が成功してから2つ目を開始してください。

1.0.0未満のnpmタグ

1.0.0未満の公開済みバージョンでは、betaとlatestの両方が そのバージョンを厳密に指す必要があります。これらはnpmの配布タグです。パッケージのバージョン文字列 とGitタグは既存の形式を維持します。これによって、現在のワークフローでプレリリースのGitHub Releaseが有効になることはありません。

新しい1.0未満のバージョンでは、Actionは検証済みアーカイブを --tag stagedで一度だけステージに配置します。npmの2FA承認後、手動の完了処理でレジストリの完全性を検証し、 npm dist-tag addを使用して同じバージョンにbetaとlatestを追加します。 成功とする前に、両方のタグのマッピングを読み戻します。タグの 権限エラーや未確認のマッピングがあると、Actionは失敗状態のままになります。元のステージング実行IDで手動の完了処理を再実行し、 再ステージングや再公開をせずに、不足するタグを修復してください。各パッケージの Trusted PublisherでAllow npm dist-tagを有効にしてください。Actionは書き込みトークンへのフォールバックを使用しません。

1.0.0以上でも、ステージングでは引き続きstagedを使用し、完了処理で必要なのはlatestだけです。既存のbetaチャネルは、 このルールによって更新または削除されません。タグを公開または修復する前に、Actionは 必須チャネルをすべて確認し、より新しいバージョンを上書きする操作を拒否します。 古い公開済みバージョンを再実行する場合も同様です。このワークフロー外で 並行して書き込む処理も、同じ直列化およびチャネルの順序に関するポリシーに従う必要があります。

同じ規則は、新しいパッケージの承認済みの手動初回公開にも適用されます。 古い公開済みバージョンのタグを変更することは、別のレジストリ書き込み操作です。 この実装は、既存の0.1.0リリースのタグや内容を変更しません。

npmのGitHubデプロイ記録

2つのGitHub環境を使用します。npm-coreは https://www.npmjs.com/package/@alneas/appkit-core に、npm-reactは https://www.npmjs.com/package/@alneas/appkit-react にリンクします。publish.ymlの完了ステップは、レジストリの完全性と必須タグが一致した後にのみ、明示的なDeploymentを作成または再開します。その環境とURLは、検証済みのパッケージタグから取得します。ステージングでは、deployment: falseを使用し、OIDCの識別情報に同じ環境を使用します。承認待ちの間は、一般公開の成功記録を作成しません。完了処理でもジョブの自動デプロイを無効にし、APIを使用して、完了処理をディスパッチした新しいmainコミットではなく、元のソースコミットを対象にします。再試行時には一致する記録を再開し、競合する記録がある場合は失敗します。

0.1.0を含む公開済みバージョンについては、別の手動Actionである既存の npm公開を記録（Record existing npm publications）（record-npm-deployments.yml）を、マージ後に使用してください。 v0.1.0などの既存のタグを入力します。同じ操作は、 GitHub CLIの認証とリポジトリのDeploymentsへの書き込み権限があれば、ローカルでも実行できます。

node scripts/record-npm-deployments.mjs --tag v0.1.0
node scripts/record-npm-deployments.mjs --tag v0.1.0 --apply

最初のコマンドは、書き込みを行わずにプレビューします。2つ目のコマンドは、両方の厳密なnpm バージョンを検証し、リモートタグが指すコミットを解決したうえで、パッケージごとに1つの record:npmデプロイを作成または再開し、成功ステータスとnpmページのURLを設定します。 再試行では、一致する記録を再利用します。レジストリの整合性メタデータが競合する場合は、 手動での調査が必要です。一部が失敗した場合はエラーを返し、再試行できます。 Actionは実行を直列化します。ローカルコマンドをActionと同時に実行しないでください。 レジストリの整合性をメタデータとして記録し、自動マージを無効にし、 ほかのデプロイステータスはアクティブなままにします。npm publishの呼び出し、タグの変更、 モデル評価の実行は一切行いません。手動ワークフローは、自身のコミットに環境を割り当てるのではなく、 APIを使って選択されたタグを対象にします。

これらは過去の公開を遡って記録するものです。作成時刻は記録した 時刻であり、ペイロードには遡及的な記録であることが明示されます。provenanceを提供したり、 tarballがタグの指すソースからビルドされたことを証明したり、より新しい 作業ツリーの変更を認証したりするものではありません。Deployment API とステータスAPIを参照してください。

独立してバージョン管理されるCoreとReactの互換性

ReactのCore依存関係は、厳密なバージョンに固定してください。新しいCoreをリリースしても、 公開済みのReactパッケージは自動更新されません。両方のパッケージをビルドした後にbun run check:react-coreを 実行してください。bun run verify:pushとNode 24を使うmain更新時のCI ジョブには、すでにこの処理が含まれています。PRやブランチへのプッシュによるActionのトリガーは追加されません。

ゲートは常に、同じReactソースとパック済みReactアーカイブを、システムの一時領域にある 2つの独立した利用側環境でテストします。

• currentは、Reactが宣言する厳密なCoreバージョンを公開npm レジストリからインストールします。ワークスペースからはインストールしません。
• candidateは、ローカルでビルドしたCoreアーカイブをインストールし、互換性テストのためだけに、 ReactのCore依存関係を意図的に上書きします。リポジトリ内のパッケージマニフェストと Reactアーカイブは書き換えません。

各利用側環境は、ソースの型、Reactの単体テスト、skipLibCheck: falseを使用したNodeNextでの 公開済みESMおよびCommonJSの型宣言、ネイティブESM/CommonJSの読み込み、 ドキュメントに記載されたリクエストフォームのSSRを確認します。Reactが選択されたCoreを解決すること、 そのバージョンとアーカイブの整合性が一致すること、チェックアウトへのシンボリックリンクから 依存関係が供給されていないことを検証します。両方の組み合わせが合格する必要があります。currentの検証系統が失敗し、 candidateの検証系統が合格した場合は、依存関係の更新が必要な可能性を示します。candidateの検証系統が 失敗した場合、そのCoreの採用をブロックします。インストールエラーやネットワークエラーも ゲートを失敗させ、ローカルコマンドのログに別途報告されます。

両方の検証系統が合格していても、Coreの修正をReactユーザーに届ける必要がある場合は、Coreの変更の 作成者が同じPR内でreact-core-policy.jsonに永続的なエントリを追加します。例を示します。

{
  "schemaVersion": 1,
  "requirements": [
    {
      "id": "approval-safety-fix",
      "coreVersion": "0.1.1",
      "reactVersion": "0.1.1",
      "reason": "React users must receive the approval safety fix."
    }
  ]
}

この例は説明用です。初期状態の要件リストは空です。coreVersionは、 必須の修正を含む最初のCoreリリースを指定します。Coreの候補は、 常にそのバージョンに到達している必要があります。任意指定のreactVersionは、依存関係で その修正を採用する必要がある最初のReactバージョンを指定します。そのReactバージョンに達する前は、通常の pre-push/main CIは両方のCoreの組み合わせをテストしながら、古い依存関係をpendingRequirementsと報告します。 Reactユーザーに修正が届いたとは表明しません。 Reactバージョンの期限以降は、古い依存関係はインストール前に失敗します。 reactVersionのない要件は、引き続き即時に強制適用されます。

Reactの公開では毎回bun run check:react-core --releaseを実行し、Reactバージョンの期限にかかわらず、 記録されたCore要件のすべてを強制適用します。 予定より早いReactのリリースでも、保留中の修正を回避することはできません。この厳格なゲートは、 パブリッシャーがOIDC権限を受け取る前に実行されます。修正を採用する際には、Reactの依存関係と リリースバージョンを同時に更新することが引き続き必須です。

過去のエントリとその期限を保持してください。CIを通すためだけに要件を延期したり 削除したりしないでください。メンテナーは、Coreの修正を追加するときに採用期限を 選択し、レビューする必要があります。このマーカーは、その影響に関する判断を記録します。テストが ビジネスやセキュリティへの影響を推測したり、Reactのリリースを自動で予定したりすることはありません。

currentの検証系統はレジストリを使用するため、未公開の新しい依存関係は、 そのCoreバージョンがnpmに存在するまで失敗します。Coreの準備中は、Reactの依存先を以前の公開済みバージョンに固定したままにしてください。 採用期限を将来に設定しても、マトリクスのどちらの検証系統も変わりません。連携したリリースでは、まずCoreを 公開し、その後、更新したReactの依存関係でこのゲートを実行してからReactを公開してください。 ゲート自体は、公開、バージョンやタグの変更、実際のモデルを使う 評価を行いません。また、そのログをエージェント評価の証跡として扱いません。

このゲートはネットワークアクセスを必要とし、pre-push/CIに2回のnpmインストールを追加します。 検証記録とコマンドのログは、バージョン管理の対象外となる.verification/react-core/配下に保持します。 使い捨ての利用側環境は、完了時または失敗時に削除されます。 ポリシーと分離の決定論的テストには、bun run test:react-core-toolingを実行してください。

公開パッケージの内容

両パッケージは、MITライセンスで公開しているソースのデバッグ用に、sourcesContentを含むソースマップを意図的に同梱しています。パック済みの.mapファイルに非公開のソース内容やローカルの絶対パスが含まれていないか確認し、リリース前に圧縮アーカイブのサイズをレビューしてください。公開ソースマップに認証情報や非公開ソースを含めてはいけません。今後このポリシーを変更する場合は、実際にパックされた成果物と照合して確認する必要があります。

npmスコープ@alneasとGitHub所有者dataarthubは、別々の名前空間です。provenanceの検証も含め、repository.urlが実際のソースリポジトリを指す状態を維持してください。既存の明示的なサブパスエクスポートは、互換性に関する契約です。package.jsonの長さだけを理由に削除してはいけません。内部ファイルを公開してしまうワイルドカードで一覧を置き換えるのではなく、追加内容をレビューしてください。

公開後は、ローカルのエイリアスやアーカイブによる上書きを使わず、新しい利用側環境に厳密なレジストリバージョンをインストールしてください。ポータルへの取り込みと日本語での提供は、別の作業です。認証情報、非公開ソース、運用上の記録を公開しないでください。

任意のコーディングエージェント評価

分離されたエージェント評価の手順は、エージェント向けAPI、指示、 検出用メタデータの変更を対象とする、手動で実施する任意の回帰評価です。 すべてのnpmリリースの前提条件ではなく、公開ワークフローは 実際のモデルを実行せず、ローカルのエージェント検証記録も使用しません。この6タスクを3回ずつ繰り返す 限定的なベンチマークは、パッケージ全般の認証ではありません。

実際のモデルを使った評価を報告する場合は、引き続き、その実行で使った検証記録とアーカイブそのものに対して bun run check:agent-evalを実行してください。欠落している証跡、古い証跡、変更された証跡は、 引き続き有効とは認められません。評価を任意にしても、採点基準は緩和されず、 ハーネスの自己テストを実際のタスクの成功として報告することも認められません。未加工の証跡は、引き続きバージョン管理の対象外にしてください。