grace-verification

モジュールと変更の決定論的な検証を強化します。検証状態は `.grace/verification/index.xml` と、ルーティングされた検証ドキュメントに保存されます。明示的な例外が計画されていない限り、永続的な各モジュールには決定論的な `V-M-*` カバレッジが必要です。 1. 関連する `.grace/graph` アンカーと、現在の `V-M-*` エントリーを読みます。 2. シナリオ、コマンド、テストファイル、必須のログマーカー、トレースアサーションを特定します。 3. コマンドが決定論的であり、プロジェクトルートまたは文書化された作業ディレクトリから実行できることを確認します。 4. アクティブな変更計画を通じて、`.grace/verification` の変更を更新または提案します。 5. コマンドを実行し、新しい証拠を応答に記録します。 検証コマンドをワークスペースまたはパッケージのディレクトリから実行する場合、対象の `V-M-*` エントリーに、直接の子要素 `relative/project/path` を1つ追加します。宣言する `...` のパスはプロジェクトルート相対のままにします。CLI は `Cwd` を使って、これらのパスと cwd 相対のコマンド引数を比較します。 モジュールの健全性を、関連する実装コードから出力される実行時ログまたはトレースで証明する必要がある場合は、`` を使用します。純粋関数、型レベルのモジュール、コアライブラリなど、実行時ログを必要としない決定論的なテストまたはトレースの証拠には `` を使用します。空でないマーカーまたはトレースアサーションがあれば、モジュール健全性の証拠要件を満たします。実行時の出力との一致および `BLOCK_*` の証拠が必要なのは、作成したマーカーのみです。 インラインの `;` チェーンではなく、`MustPassCommand` と `ExpectedCommand` で名前付きのプロジェクトタスク（例：`bun run gate:e2e`）を参照します。大規模なゲートは、名前付きの細分化されたタスク（`gate:test`、`gate:typecheck`、`gate:build`、`gate:e2e`）に分割します。これにより、選択して再実行する際は該当タスクを実行するだけで済み、タイムアウトは一貫した単位に対応し、`grace lint --run-commands` は各ゲートの手順を個別のタイミングとログとともに報告します。 不安定なゲートは、検証エントリー側の不具合であり、むやみに再実行する理由にはなりません。`~/.cache/grace/run-commands/` 配下の試行ごとのログから原因を診断します。ゲートタスクの分割、タスク内でのランナーレベルの再試行の追加（例：playwright の `--retries`）、または不安定なシナリオの隔離によって修正します。手動で黙って再実行しても解決にはなりません。grace はすべての実行を正確に記録し、非決定的な検証はアサーションの証拠を損ないます。