gjalla-prepare-and-commit

変更をコミットできる状態にする

作業中の変更を、レビュアーや将来の読者が信頼できる、コミット可能な変更に仕上げます。

1. 実装内容をレビューする

• すべての検証基準と期待される結果を満たしていますか？
• 実装は完了していますか（ダミーデータやプレースホルダーのスタブが残っていませんか）？
• gjalla のルールをすべて満たしていますか？
• 既存の状態／アーキテクチャ／プロパティを活用し、その中に洗練された形で組み込まれていますか？
• 計画／gjalla の仕様に合っていますか？
• 正常系、異常系、境界ケースを十分に目立つ形でテストしていますか？
• コードレビューのプロセスは完了していますか？

これらの質問のいずれかに「いいえ」と答える場合は、必要な変更を判断してください。場当たり的な変更は一切許容できません。問題に対する洗練された持続可能な解決策を設計するために、いったん立ち止まるほうが適切です。人間によるレビューが必要なトレードオフがある場合は、ユーザーに確認を求めてもかまいません。

すべてに自信を持って「はい」と答えられるようになったら、何を検証したか（実行したテストスイート、終了コード、DoD 項目）を記録し、変更概要に主張だけでなく根拠を示せるようにしてください。

2. プロセスを提示する（2 つ目の人間による確認）

• 人間向けに、実施したフェーズ、その各フェーズの根拠（レビュー、テスト実行、DoD）、システムへの影響を記した短い変更レポートを作成します。

• このレポートは人間による確認のためのものです。「実施したフェーズ、その各フェーズの根拠（レビュー、テスト実行、マイルストーン）、システムへの影響」を示します。封印する前に、人間へ提示するか、要点を提示してください。ただし、低リスクの変更に対する恒常的な承認を得ている場合は除きます。

3. コミット計画を立てる

• 1 つのコミットにつき、論理的な変更を 1 つにします。差分に無関係な変更が 2 つ含まれている場合は、ためらわずに分割してください（git add -p）。
• 対象ファイルを正確にステージします。まとめてステージする方法（git add -A／-u／.）では、進行中の無関係な作業がコミットに紛れ込むことがあります。
• 正しいブランチにコミットしていること、または想定されたブランチ戦略に従っていることを確認します。
• git に報告する内容（コードレベルの変更）と gjalla に報告する内容（システムレベルの変更）を準備します。
• gjalla の git フックがすでに設定されていることを確認します。設定されていない場合、アテステーションと仕様が信頼できる唯一のマスターソースに同期されません。

4. コミットする

• gjalla のアテステーションを作成します。gjalla attest --example で形式を確認できます。出力全体を必ず確認してください（たとえば、コマンドを実行して 2>/dev/null にパイプすることは避けてください）。
• コミットメッセージを作成して、コミットを実行します。gjalla のアテステーションと仕様は git フックによって gjalla に同期されるため、追加の作業は必要ありません。
• ユーザーから包括的な許可を得ていない限り、コミットをプッシュする前にユーザーへ確認するのがよいでしょう。