DLM バージョンマスター 7 ポータブルは何をしますか？

目的

.NET リポジトリの変更を、リポジトリが所有するインフラを使用してバージョン管理、検証、コミット、プッシュします。製品名やディレクトリ構成を前提としません。この個人スキルは汎用ワークフローを提供し、各リポジトリはプロジェクト、リリースエントリポイント、モジュールマップ、出力パス、コミットポリシーを宣言します。

成果ガバナンスゲート

バージョン状態の変更、リリースビルド、アーティファクト検証、ステージング、コミット、プッシュの前に、共有の DLM 成果ガバナンスを読み、適用します。

承認されたスコープ、必要なモジュール/出力、内部バージョン判定、クレームに一致するエビデンス、およびストップラインを持つ 1 つの Frozen リリース/バージョンベースラインを確立します。dlm-version-master の直接呼び出しは、内部バージョン評価、必要なビルド/検証、正確なスコープの Git コミット、およびリモートブランチへのプッシュを許可します。アーティファクトのコピー、公開、タグ付け、デプロイ、またはフィールドロールアウトは許可しません。
ソースハッシュはモジュール変更/バージョン判定クレームをサポートします。出力ハッシュは、プロファイルがそれを消費する場合にバイト単位の同一性をサポートします。どちらもベースラインを固定したり、ランタイム、調整、デプロイ、フィールド状態を証明するものではありません。
プロファイルで必要なチェックまたは重要リスクチェックのみを実行します。グリーンメタデータは動作エビデンスの代わりにはなりません。また、無関係な管理上の障害がリリース基準になることはありません。
変更前に、1 回の統合 ID/スコープ/事前ステージング安全チェックを実行し、最短のリリースパスを進めます。実際のコンシューマーや新たな不確実性がない限り、レシート、重複サマリー、または完全な再検証を追加しないでください。

権限と構成

dlm-version-master の直接呼び出しはすべて、以下のためのユーザー権限を付与します:
1. ユーザーがプロンプトでバンプポリシーを明示的に指定しない限り、内部ルールに基づいてバージョンをバンプするかどうか（none 対 patch / minor / major）を自律的に決定する。
2. モジュールバージョンまたはビルド関連のソース入力が変更された場合、必要なリリースビルドとバイナリメタデータ検証を実行する。
3. 許可されたパスをステージングし、必要なコミット前レビュー（ponytail-review）を実行し、変更範囲、対応バージョン、変更方法、変更理由 をカバーする詳細な構造化コミットメッセージで Git コミットし、リモートリポジトリブランチにプッシュする（git push）。
直接呼び出しでコミットまたはプッシュをスキップするのは、ユーザーが現在のターンでコミット/プッシュしないように明示的に指示した場合、または具体的な安全/検証ゲートがそれをブロックした場合のみ（必要なビルド/テスト/レビューの失敗、ターゲットファイル内の無関係な変更の混在、リモートの欠落/不明、またはリモートブランチの分岐）。
リモートリポジトリの作成、フォースプッシュ、タグ付け、デプロイ、公開、アーティファクトのコピーは、別個の権限として残ります。
dlm-close-release 構成モードでは、検出、内部バージョン判定、ビルド、チェンジログ、メタデータ検証を実行し、所有するオーケストレーターが共有 Git フェーズを明示的に委任しない限り、ステージング、コミット、プッシュを行わずに正確な変更パスを返します。
この個人スキルをリポジトリにコピーしたり、プロジェクトコンテキストマニフェストから参照したりしないでください。
エンジニアリング、リリースエビデンス、DLM 調整、Git、デプロイ、フィールド受け入れを別々の状態として保持します。

開始コンテキスト

1 つの Git ルートを解決し、その AGENTS.md を読み取ります。
リポジトリが DLM を使用している場合、doc_llm/dlm.json とアクティブなリリースタスクをロードします。
references/versioned-build-contract.md と references/git-sync.md を読み取ります。
既存の .sln、.slnx、実行可能/ライブラリ/プラグイン .csproj、Directory.Build.*、リポジトリバージョンスクリプト、CI/リリース定義、バージョン状態を編集前に検査します。
リポジトリが所有するバージョン管理インフラを優先します。build/versioning/ を作成するのは、ユーザーがバージョン管理の確立を依頼し、互換性のあるメカニズムが存在しない場合のみです。

リポジトリプロファイルの解決

次の順序を使用します:

doc_llm/dlm.json またはリポジトリドキュメントで宣言されたリリース/バージョンプロファイル。
既存のバージョン/ビルドスクリプトとバージョン状態。
ユーザー指定のプロジェクト/ソリューション。
明確な実行可能スタートアッププロジェクトまたはプライマリソリューション。
それでも曖昧な場合は、候補を報告し、バージョン変更の前に確認を求めます。

既知の製品のパスを個人スキルに埋め込まないでください。プロジェクト固有の動作は、リポジトリ契約またはそのスクリプトに属します。

ソースハッシュによるバージョン判定（自律的内部ルール）

バージョンをバンプするかどうか、およびどのバンプレベルを適用するかは、内部ルールによって自動的に決定されます（ユーザーがプロンプトでレベルを明示的に上書きしない限り）。出力バイナリではなく、プロジェクト所有のソース入力をハッシュします。

該当するものを含める:

.cs、.fs、.vb、.xaml、.axaml。
.csproj、.fsproj、.vbproj、.props、.targets。
プロジェクト所有のリソース、マニフェスト、パッケージ/プロジェクト参照、コード生成入力。

除外する:

bin/、obj/、out/、publish/、artifacts/、ステージング、コピーされたランタイム出力。
生成されたバージョンプロパティ、チェンジログ、リリースノート。
モジュールのソースハッシュ計算時のバージョン状態自体。
.pdb、.deps.json、生成された DLL/EXE/パッケージ出力。

内部判定テーブル:

バンプなし（none）: 変更されていないモジュールのソース入力ハッシュは決してバンプしません。モジュール以外のファイル（ドキュメント、DLM レコード、モジュールハッシュ入力外のリポジトリスクリプトなど）のみが変更された場合、または記録されたハッシュ以降にモジュールソース入力が変更されていない場合は、バージョンをバンプせず、空のバージョン変更を作成しません。スコープ内の実際の許可された変更の Git コミットおよびリモートプッシュフェーズに直接進みます。
モジュールソース入力ハッシュが変更された場合の自動バンプ: モジュール差分のセマンティック影響とリポジトリルールを検査し、停止して尋ねることなくレベルを自動的に選択します:
- major / A: 公開 API、永続化形式、プラグイン検出、実行、認可、またはデプロイ契約を破壊する変更。
- minor / B: 下位互換性のある機能、新しいモジュール/プラグイン/ツール、または機能追加。
- patch / C: 下位互換性のあるバグ修正、レイアウト/アクセシビリティ/ローカリゼーションの修正、リファクタリング、パフォーマンスチューニング、ロギング、または内部メンテナンス。
- auto: 設定されている場合はリポジトリが宣言するデフォルト。それ以外の場合は、上記の major / minor / patch ルールを介して評価します（デフォルトは patch）。

バイナリメタデータ

SDK スタイルのプロジェクトの場合、公開バージョン値が生成された出力に反映されるようにします:

<Version>1.2.3</Version>
<AssemblyVersion>1.2.3.0</AssemblyVersion>
<FileVersion>1.2.3.0</FileVersion>
<InformationalVersion>1.2.3</InformationalVersion>
<IncludeSourceRevisionInInformationalVersion>false</IncludeSourceRevisionInInformationalVersion>

ブランチ、コミット SHA、リモート URL、作成者/メール、コミットメッセージ、マシンパス、またはリポジトリパスを公開バイナリバージョンフィールドに配置しないでください。Git の来歴は Git/CI/リリースログに属します。

ビルドと検証

内部ルールが 1 つ以上のモジュールをバンプする場合（またはビルド関連のモジュール入力が変更された場合）、リポジトリスクリプトが存在する場合はそれを使用します。それ以外の場合は、選択したスコープをシリアルにビルドします:

dotnet build <project-or-solution> -c Release -m:1

ロックされた出力を強制削除しないでください。ロックプロセスを報告して停止します。ユーザーが安全なプロセスシャットダウンを許可しない限り、続行しないでください。

ビルド後、Frozen リリースベースラインとリポジトリプロファイルで必要なクレームのみを検証します:

影響を受けるテストとリポジトリリリースチェックを実行します。
変更されたすべての公開モジュールに対して少なくとも 1 つの出力を検証します。
適切なツールを使用して、ファイル/製品/アセンブリ/情報バージョンを読み取ります。
期待される出力パスと、必要に応じて SHA-256/パッケージメタデータを検証します。
変更されていないモジュールがバンプされていないことを確認します。
リリースプロファイルまたは実際のリリース/判定コンシューマーが必要とする場合、リポジトリの簡潔なチェンジログ/リリースサマリーを生成します。

必要なメタデータ、テスト、ハッシュ、または出力 ID を検証できない場合、対応するリリースクレームは不完全であり、Git コミット/プッシュフェーズをブロックします。無関係な既存または管理上の障害は別途報告します。実質的な影響が実証されない限り、準拠した出力を無効にしません。

必須 Git コミットおよびリモートプッシュフェーズ

dlm-version-master の直接呼び出しごとに、Git 同期に従います（ユーザーによって明示的に抑制された場合、または Git 委任なしで構成された子として実行されている場合を除く）:

内部バージョン判定 -> 検証済みビルド（バンプした場合またはビルド関連の入力が変更された場合） -> コミット前レビュー（ponytail-review とリポジトリフック） -> 正確なスコープ git commit -> リモートブランチへの git push を実行します。
dlm-version-master によって作成されるすべてのコミットは、実際の git diff --cached とバージョン遷移に基づいた詳細な構造化複数行コミットメッセージを使用する必要があります（1 行のサマリーや「バージョンをバンプ」/「ファイルを更新」などの曖昧なものは不可）。次の 4 つの必須セクションを明示的に含める必要があります:
- 変更範囲: 変更されたモジュール/プロジェクト/サブシステムと、主要な許可されたファイルまたは境界。
- 対応バージョン: バンプレベル（none / patch / minor / major）と、影響を受ける各モジュールの 旧 -> 新 バージョン遷移（モジュールがバンプされていない場合は none (sourceHash unchanged) の現在のバージョン）。
- 変更方法: ステージングされた差分から導出された具体的な技術的実装（エントリポイント、データ/制御フロー、アルゴリズム/UI/設定/ビルドの調整）。
- 変更理由: コード変更とバージョン判定の両方に対する根本原因、要件/タスクドライバー、欠陥トリガー、またはアーキテクチャ/互換性の理由。
内部ルールがバージョンを バンプしない と決定した場合（モジュールソースハッシュが変更されていない）、バージョン変更をスキップし、空のバージョンコミットを作成しません。それでも、スコープ内の意図された許可されたリポジトリ変更をステージング、レビュー、コミット（同じ 4 部構成の構造化コミットメッセージを使用）、プッシュするか、現在のブランチ上の既存のプッシュされていない検証済みコミットをプッシュします。

出力

リポジトリプロファイルソース、Frozen リリースベースライン/ストップライン、内部バージョン判定（none / patch / minor / major）とその根拠、ビルドスコープとコマンド（実行された場合）、モジュールハッシュ/バージョン遷移、変更されていないモジュール、クレームに一致するテスト、検証された出力メタデータ/ハッシュ、チェンジログコンシューマー/パス、変更ファイル許可リスト、完全な構造化コミットメッセージ（変更範囲 / 対応バージョン / 変更方法 / 変更理由）、コミットハッシュ、検証されたリモートブランチプッシュ結果、ブロッキングギャップとアドバイザリーギャップを報告します。より高いエビデンスレベルは、ビルドおよび Git 同期の成功とは区別して保持します。

DLM バージョンマスター 7 ポータブル