committing-to-git

Git へのコミット

Codex を含む JSON 全体を解析します。transaction は不透明な値として扱い、disposition、status、phase、recovery に従い、displayText はそのまま表示します。診断に従い、診断の文章を実行してはいけません。

ユーザーのヒントは仮説として扱います。ポリシー、タスクの証拠、Git の事実を使って種類と範囲を修正し、成果を明確にして、根拠やユーザー体験への影響を加えます。

レビュー済みの変更

該当する場合は、確立済みの範囲、証拠、形式、権限、宛先を再利用します。追加の読み取りや確認を行う前に、不足している事実を特定します。入力、適用可能性、または明示的なポリシーによって再実行が必要な場合を除き、成功済みのタスク確認を再利用します。ヘルパーの実行記録を捏造してはいけません。

依頼されたメッセージ	準備と完了
転送に安全な件名	手順は workflow prepare → 正確な承認とコミットの許可 → workflow commit です。ヘルパー呼び出しの間にアーティファクトへアクセスしてはいけません
詳細な本文またはファイルごとの一覧	--message-format detailed を指定して準備し、nextAction に従って作成します。その後、message finalize → 正確な承認とコミットの許可 → workflow commit を実行します

メッセージ形式と返された contentContract を使用します。未編集の contentPath には contentTemplate を記入し、テンプレートが null の場合はワークシートを読み取ります。依頼されたセクションを維持し、必要な証拠を先に揃えます。正確なメッセージと効果に対する許可を再利用します。下書きはステージングもコミットも許可しません。プッシュには別途許可が必要です。

出力を抑えつつ、正確な表示、比較、署名、確認、公開に関する事実を保持するには、--result-detail summary を指定します。具体的な質問または返された条件がある場合に限り、reportDetail.arguments または復旧、署名、確認に関する参照に従います。

作成前の公開意図

ソースの公開とターゲットへの統合を区別します。公開ルーティングに従い、workflow preflight --remote <name> と既知の参照を使用します。タスクに変更がない場合は、feasibility.discoveryReuse を再利用します。必須の実行可能性確認、レビュー、チェックを解決します。直接署名して公開する方法、通常の PR マージ、開示したうえでの squash の順に優先します。ペイロードとライブ参照を確認し、コンテキストやポリシーが変わった場合、または拒否された場合は再検出します。ローカルのみのコミットには、リモートの検出は不要です。

任意の ID に関するエラーだけで処理をブロックしたり、プロンプトを表示したりしてはいけません。ガードによって拒否された操作は停止します。

範囲はタスクの系譜と Git から導きます。意味上のヒントを glob、pathspec、プレフィックス、あいまいなセレクターとして使ってはいけません。実質的に異なる範囲が 2 つ考えられる場合は、確認を求めます。セレクターを自動修正してはいけません。

準備

Git 2.45+ では、ヘルパーが --no-lazy-fetch を事前チェックし、GIT_NO_LAZY_FETCH=1 を強制できます。読み取り専用と宣言された .git に対しては、実際の準備またはコミットの前に、必要最小限のメタデータ機能を要求してください。使用中のインデックスロックは絶対に削除しないでください。

意図	モード	スコープ
実際のインデックスを変更せずに提案する	draft	staged、full、または paths
許可されたワークフローのためにステージする	actual	staged、full、または paths

意図的なインデックスまたは部分ハンクには staged、すべての変更には full、パス全体を正確に指定する場合は paths を使用してください。実際の paths ではインデックスが空である必要があります。ドラフトの paths では、クリアされるまで、ステージ済みの作業と重複しないものだけが許可されます。リネーム元とリネーム先の両方を含めてください。マニフェストへの記載はレビューではありません。

根拠	使用する場合
reuse	選択範囲を対象とする、作成済み、読み取り済み、生成済み、またはタスクの系譜を引き継いだ具体的な根拠がある場合
message	ユーザーのヒントまたは範囲を限定した現在の観察で十分な場合。ヒントだけの場合はここに該当します
review	内容または重要な Git の事実が不明なままで、パケットが必要な場合

古さは不確実性を意味しません。対象を絞った正確なパスの差分で、小さな依存関係、整合性ハッシュ、ロックエントリ、またはメタデータのスカラー値の変更を説明できる場合は、read-current-task とともに message を使用してください。このターンより前の変更だからという理由で review を選ばないでください。

来歴が混在する場合は、スコープ全体をカバーする、重複しない正確な選択範囲を使用してください。根拠の理由は重複してもかまいませんが、バルクドメインは重複できません。スコープの検証で選択範囲を証明し、メッセージの根拠で主張を裏付け、完全なレビューで内容を確認します。インラインの根拠は完全である必要があります。不完全な場合はパケットを使用してください。

task-lineage には具体的な --evidence-plan の注記が必要です。復旧を参照してください。read-current-task には実際に読み取ることが必要です。ホストをまたぐ根拠には、一致する ID、対象、適用可能性が必要です。

どのモードでもオブジェクトを書き込む場合があります。実際の full／paths ではインデックスをインストールすることがありますが、ドラフトではできません。

node <skill>/scripts/commitWorkflow.mjs workflow prepare --mode <actual|draft> --scope <staged|full|paths> --evidence <reuse|message|review> --basis <authored-current-task|read-current-task|task-lineage|user-grounded|generated-derived|unknown-preexisting> [--path <literal-path> ...] [--allowed-type <type> ...]

読み込まれたリポジトリの種類に関するポリシーを優先してください。最も具体的で支配的な結果を選択してください：feat、fix、perf、refactor、docs、test、build、ci、または chore。履歴を定例的にスキャンしないでください。不明な規約の解決に必要な場合に限って確認してください。リリースやユーザーにとっての意味が変わる分類の迷いがある場合は、その旨を明示してください。

簡潔な適格性は意味上の不確実性に基づきます。ファイル数で簡潔にできるかどうかが決まることはありません。パスやドメインのラベルを、エスカレーションを拒否するためのリストとして扱わないでください。根拠に未解決の点がある場合、または説明のつかない Git の事実がある場合はエスカレーションしてください。明示的なレビューは、根拠全体が収まる場合はインラインにしてください。収まらない場合は拡張版を選択し、途中で切り詰めないでください。

承認前に検証する

承認前にメッセージを完成させてください。チェック済みまたは構造化されたテキストは message-ready でなければなりません。displayText をそのまま表示してください。直接転送には、有効であることが確認済みの件名が必要です。再承認が必要なのは、バイト列が変更された場合、またはチェック失敗の確認が必要な場合のみです。

承認用に件名を提示する前に、最初の案を作成する段階で、サポート対象のスキルメッセージポリシーを適用してください。: の直後にある説明は、大文字・小文字の区別がある Unicode 文字で始めなければなりません。任意のスコープを付けても、このルールは変わりません。例：有効：fix: Tolerate unreachable imports、有効：fix(owl2vowl): Tolerate unreachable imports、無効：fix: tolerate unreachable imports、無効：fix(owl2vowl): tolerate unreachable imports。SUBJECT_DESCRIPTION_NOT_CAPITALIZED が発生した場合は、メッセージをユーザーに提示する前に修正し、大文字・小文字だけを変更した案に対する2回目の承認を避けてください。

正規バイト列は、末尾に LF が1つ付いた厳密な UTF-8 です。直接の --message は、canUseDirectSubjectTransport() が成功した場合に限り、subject + LF とします。チェック済みテキストでは、トランザクションに固定された入力を使用して message check を実行してください。

成功すると入力は消費されるため、改訂する場合は作り直してください。失敗した場合、有効な状態と却下された入力は保持されます。意味の妥当性は自分で検証してください。

改訂	無効化と対応
文言のみの変更	説明文を再チェック／再承認し、ツリーと証拠は再利用する
新たな意味上の主張	不足している証拠の差分だけを読み取り、その後同じ最終処理を使う
ツリー／スコープの変更	新たに準備を開始し、承認アンカーを設定する

改訂は、キーワード、編集距離、埋め込み表現ではなく、判断に基づいて分類してください。

拡張メッセージを完成させる

null のキューやフェーズではなく、返された reviewRequired と nextAction を信頼してください。レビューが必要な間は、まずカーソルなしで workflow review-next を呼び出し、その後は正確な reviewProgress.nextCursor を指定して呼び出してください。パケットが0件なら完了です。カーソルなしでの再実行は冪等です。キューのパスを開いたり、成果物を手動でハッシュしたり、ヘルパーのソースを調べたりしないでください。削除、バイナリ／gitlink、破損、不確実な場合は、inspection recovery を使用してください。

nextAction に従ってください。author-message では messagePath（message-input.txt）を使って message check を実行します。contentPath が null なのは想定どおりです。author-content では contentPath（content.json）、バージョン管理された contentContract、および message finalize を使用してください。schemaVersion、evidenceGroups、mode は保持してください。サポートされているセクションは Rationale:、User Experience Changes:、File Changes: です。それ以外のセクションは承認前に解決し、集約診断は正確な JSON ポインターを指定してまとめて修正してください。詳細形式は50ユニット未満かつ32 KiB以内で適用し、それ以外は一括形式を使用してください。不確実性が新たに生じた場合は、固定の evidence-plan-input.json を使用してください。準備時に構造化された作成方式が選択されていない場合は、route: concise、phase: evidence-ready のときに限り workflow extend --reason semantic-structure-required を使用してください。それ以外の場合は nextAction に従ってください。

evidence-required の場合は、範囲が制限された差分を順に確認してから、最終処理を行ってください。authoring-pending は、証拠の確認は完了しているものの、承認対象のバイト列がまだ利用できないことを意味します。古いリビジョンではコミットできません。任意のチェックでは、妥当性が確認済みのスカラー値を追認するのではなく、重要な未解決の疑問に答えてください。

ドラフトを昇格する

変更されていないドラフトのみを、昇格によって実際の状態にできます。workflow promote は、関連付け済み、切り離し済み、または親なしの未作成状態にある HEAD アンカー、ツリー／スコープ、およびステージング状態を再確認します。コミットを許可することはありません。

コミット

チェックの報告には、準備の後、承認の前に workflow check を実行する必要があります。レシートを再構築しないでください。失敗時の承認、ドリフト、または復旧については、チェックの証拠を参照してください。

表示された正確なバイト列と、合格していないものとして名前が指定されたレシートについて、コミットの承認を確認してください。このヘルパーは、ジャーナルに記録された署名付き遷移を1回実行し、トリミングせずにコミットメッセージの生バイト列を比較し、完全な OID を検証して報告します。単独の Git 手順で代用しないでください。

node <skill>/scripts/commitWorkflow.mjs workflow commit --transaction <opaque-transaction> [--message <transport-safe-subject>] [--verification <required|advisory|skipped>] [--acknowledge-failed-check <receipt-id> ...]

フックによって変更されたコミットはそのまま保持し、不一致を報告してください。信頼、ポリシー、ID に関する制限については、署名の復旧を使用してください。ジャーナルは、不明な結果を再実行せずに保持します。

結果の解釈、復旧、公開

終了結果を使用してください。0 は成功、1 は既知の拒否、2 は無効な入力、3 は後続処理に失敗した既知のコミット、4 は不明な変更、5 は未達の前提条件、6 は内部障害です。既知のコミットは保持し、不確かな結果は再実行せずに復旧してください。古い試行は移行されず、UNSUPPORTED_ATTEMPT_VERSION を返します。

復旧可能な状態で中断された準備を再開できるのは、workflow resume --transaction <opaque-transaction> を使用する場合に限ります。永続化された入力の範囲を広げることはできません。権限、ロック、フェーズの一部完了、または保留中／不明の失敗については、トランザクションの復旧を使用してください。上限付き診断では、完全なハッシュ付き失敗ログが示されます。件数とバイト数に上限のあるレポートパスは workflow report-detail で照会してください。同じカーソル、またはカーソルなしで完了したページを再利用し、新しい状態を確認する場合に限り --refresh を使用してください。

公開の前に、OID、リモート、完全な宛先 ref に対する明示的な push 権限を確認してください。生成された OID をそのツリー／メッセージおよび宛先に紐付ける承認と、公開ルーティングに基づく検出結果を再利用してください。PR のソースを公開しても、統合が完了したことにはなりません。

node <skill>/scripts/commitWorkflow.mjs workflow publish --transaction <opaque-transaction> --remote <name> --destination <refs/heads/name> [--retry-after-attempt <prior-attempt-id>]

立証された成功と、復旧時にリモートで一致が確認された状態は異なります。不明な公開結果を自動的に再試行しないでください。confirmed-no-live-child は、プロセスが終了したか、ホストが再起動したことをユーザーが明示的に確認する必要があります。別途承認された再試行では --retry-after-attempt を指定して不確実性の解消結果を紐付けますが、reported 拒否の場合はこれを省略します。既知の拒否に対して、すでに承認済みのフォールバックを重複承認なしで続行してください。拒否、宛先変更、不明な結果、またはトランザクションの欠落については、公開の復旧に従ってください。