ln-62-repository-publisher

リポジトリの公開

目標： ユーザーが承認した変更のみを公開し、その結果をリモートソースから検証します。

実行上の契約： 順番に並んだチェックボックスが完了の定義です。各項目を内部的に PENDING、具体的な証拠がある PROVEN、条件が存在しないことを示す証拠がある CLEARED、または不足がある UNPROVEN として記録してください。読み取り、委任、ツールの失敗は証拠になりません。各セクションの後に項目を見直してください。返答する前に、すべての PENDING を解消し、PROVEN と CLEARED のみを数えます。不足がある場合は、スキルの判定ルールと承認ルールを適用してください。 ユーザーの意図、対象範囲、既存の承認を尊重してください。承認済みの作業は続行し、重大な未決事項や必須の外部承認についてのみ確認してください。重要度に応じて検証の深さを調整し、確認項目を黙って省略しないでください。依存関係と安全上の順序を守り、それ以外は各要件に適した検証方法を選んでください。

ツールの使い分け

必要な作業	優先する機能	代替手段
対象範囲、ステージング、履歴、同期の確認	ネイティブの Git CLI	同等の Git 証拠を取得できない場合は停止
リポジトリの検証	プロジェクト固有のコマンドとインストール済みのバリデーター	文書化された手動チェック
リモートブランチと CI の状態確認	認証済みのホスティング CLI またはコネクター	Git のリモート情報とワークフローへの直接 URL
クリーンなソースでの検証	配布対象に変更がある場合は、一時クローンと分離されたホスト設定	リモートの raw ファイルと、必須のインストール証拠が得られない場合は BLOCKED
静的サイトの検証	デプロイワークフローと直接の HTTP リクエスト	ホスティング API のデプロイ状態
現在のマーケットプレイスの動作確認	ホストの公式ドキュメント	前提を明示し、破壊的な再試行を避ける

まず簡潔な Git 出力を確認し、ステージングするファイルについては完全な差分を開いてください。失敗した終了コードが隠れるようなコマンドのパイプ接続は避けてください。

リモートの事実にはホスティング API を、リポジトリの事実には Git を使用してください。ローカルの配布状態やデプロイ状態では、リモート利用者向けの更新が機能することを証明できません。

チェックリスト

対象範囲と証拠の確認

• ユーザーがコミットとプッシュを明示的に依頼したことを確認し、対象のブランチを特定します。
• 変更を加える前に、リポジトリの指示、リリースルール、現在のブランチポリシーを読みます。
• git status -sb、ステージ済みおよび未ステージの差分、未追跡ファイル、リモート、直近のコミット形式を確認します。
• 無関係なユーザー変更を特定し、作業ツリー全体への明示的な許可がない限り、それらをステージングしません。
• 削除や生成ファイルも、編集したテキストと同じように注意深く確認します。
• 動作、インストールコマンド、カタログ、レイアウト、公開サイトに、対応するドキュメントの更新が必要か確認します。
• 通常の公開では、依頼またはリポジトリポリシーに明示されていない限り、バージョン、タグ、リリースメタデータを変更しません。
• マーケットプレイスの編集では、意図的な移行が承認されていない限り、すべての安定識別子が変更されていないことを確認します。
• 複数のホストカタログがあり、リポジトリポリシーで同一性が求められる場合は、指定順で同じ配布単位が含まれていることを確認します。
• マニフェストやカタログ間でメタデータが重複している場合は、説明とソースパスが正規のソースと一致することを確認します。

検証のルーティング

• 一般的なチェックを行う前に、リポジトリ固有の検証コマンドを確認して実行します。
• 変更したスキルについて、リポジトリで必須とされる、またはホストネイティブのスキル検証ツールを実行するか、文書化された手動の代替手順を実施します。
• 変更したプラグインまたはパッケージについて、リポジトリで必須とされる検証ツールを実行するか、文書化された手動の代替手順を実施します。
• 配布対象が存在し、変更されたか、リポジトリのポリシーで必須とされるすべてのホストネイティブの厳格な検証ツールを実行します。
• リポジトリおよび影響を受ける対象で必須とされる、カタログの整合性、マニフェストの解析、古い参照、ローカルリンク、空白文字のチェックのみを実行します。
• 関連するプロダクトテストのみを実行します。リポジトリのポリシーにない、大がかりなリリース前チェックを独自に追加しないでください。
• 必須チェックの失敗が確認された場合、ユーザーがその失敗を明示的に了承しない限り、コミット前に作業を止めます。
• スキップしたチェックについて、不足している依存関係または環境を正確に記録します。

同期とコミット

• コミット前に対象のリモートをフェッチし、ローカルの HEAD とリモートブランチを比較します。
• 遅れまたは分岐がある場合は両方の履歴を確認し、ユーザーの変更を保持しながら、許可されたブランチのワークフロー内で差異を解消します。意味上の競合が解決できない場合、または履歴の書き換えが必要な場合は作業を止めます。暗黙的に強制プッシュしないでください。
• 作業ツリーに複数の変更が混在している場合は、明示したパスをステージします。作業ツリー全体のステージは、ユーザーがすべての変更を承認した場合に限ります。
• ステージ後に、ステージ済みの差分と diffstat を確認します。
• ユーザー所有のファイルは削除せず、シークレット、ローカルキャッシュ、一時成果物、意図しない認証情報をステージ対象から除外します。意図した変更にシークレットが含まれる場合は、その公開を阻止し、情報を伏せた証拠を報告します。
• リポジトリのコミットメッセージ規約に従い、ステージされた変更全体を要約します。
• 設定されたコミット署名と帰属ポリシーを維持します。貢献者の ID を勝手に作成したり、必須の署名を無効にしたりしないでください。
• コミットを作成し、完全な SHA を記録します。
• ブランチ保護を変更したり、強制プッシュしたりせず、許可されたブランチにプッシュします。

リモートの検証

• Git またはホスティング API を通じて、許可されたリモート上で公開済みのコミットを検証します。ID または同期状況が不確かな場合に限り、2 つ目の情報源を使用します。
• プッシュしたコミットに対する必須の CI を、上限を設けて待機し、実行への直接 URL を記録します。待機を継続できない場合は、保留中の状態を PARTIAL として報告し、成功とみなさないでください。
• 静的サイトに変更がある場合は、デプロイを待ってから、キャッシュ回避リクエストで公開コンテンツを検証します。
• インストール対象またはマーケットプレイスのコンテンツに変更がある場合は、権限があり利用者がアクセスできるリモートをクリーンな一時ディレクトリにクローンし、影響を受ける配布対象を検証します。
• インストールまたは更新の動作に変更がある場合は、文書化された配布元から、影響を受けるパッケージまたはプラグインを少なくとも 1 つ、隔離されたホスト設定でテストします。
• 安定した配布識別子またはバージョンが存在する場合は、インストールされた成果物が想定どおりの識別子とバージョンで解決されることを検証します。
• 一時的なホスト設定はユーザーの現在の設定から隔離し、その後、安全に削除します。
• ローカルの作業ツリーと HEAD を、公開済みのコミットと再度照合します。リモートが同時に進んでいた場合は、公開済みのコミットがリモートに含まれていることを検証し、両方の SHA を報告します。一致させるために新しい変更を上書きしないでください。

安全性のゲート

• 出力に認証トークンや認証情報の値を決して含めないでください。
• 明示的に依頼されていない限り、リリース、タグ、パッケージの公開、ディスカッション、プルリクエストを作成しないでください。
• 副作用としてリモートブランチを削除したり、デフォルトブランチを変更したりしないでください。
• ブランチ保護、認証、必須チェックを回避するのではなく、BLOCKED を返します。

判定

• PUBLISHED — コミット、プッシュ、必須の CI、および該当するリモート検証が成功しました。
• PARTIAL — プッシュは成功しましたが、非破壊的なリモート確認が保留中、または失敗しました。
• BLOCKED — 認可、同期、検証、またはリモートアクセスの失敗により、公開が完了しませんでした。

セルフチェック

• 返答前に整合性を確認してください。 項目ごとの根拠、要件の網羅性、矛盾、対象範囲、判定、および該当するクリーンアップを確認します。レポートまたは認可された成果物を修正してください。有効な根拠は再利用し、リポジトリを自動的に再スキャンしたり、成功済みのコマンドを再実行したりしないでください。関連する変更、失敗、または未解決の根拠がある場合に限り、確認を繰り返します。残る不足事項を明示してください。

出力仕様

ユーザーの言語で、次の順序で報告します。5つのフィールドをすべて残し、各事実は1回だけ記載してください。短い結果はフィールドごとに1行で記載してもかまいません。空の表は省略し、リンク先の成果物をコピーしないでください。

1. 結果： スキル固有の判定と、根拠で裏付けられた結果。
2. 対象範囲： 確認・変更した範囲、除外事項、ベースライン、および重要な前提。
3. 根拠： 以下のスキル固有の項目。事実、推論、未検証の主張を区別します。成果物にリンクし、必要に応じて表を使用します。
4. 検証： 確認事項と結果、入手できない根拠、該当するクリーンアップ／外部状態。
5. 完了状況： Checklist: X/Y complete。Incomplete: None、または各 UNPROVEN 項目について、その理由、結果への影響、具体的な次のアクションを記載します。残存リスクと必要な判断事項も記載します。

スキル固有の根拠： 公開・除外したパス、ブランチ、完全なコミット SHA、リモート URL、検証結果、CI／デプロイの URL、および該当するクリーンソースからのインストール／更新の証明。PARTIAL の場合は、プッシュ済みコミットをそのまま残しても安全かどうか、および検証が完了したと確認できる事象を記載します。リモート上のコミットと、該当する必須ワークフローのすべてが確認できた場合に限り、PUBLISHED を使用してください。