slice-and-spine-review

スライスとスパインのレビュー

エージェントによる事前準備サイドカーを伴う、人間主導のリポジトリ全体の整合性確認です。個々の変更はそれぞれ sliced-bread-review、sliced-bread-depth、sliced-bread-audit を通過していても、スライス間やスパインとの境界には、範囲を限定した差分チェックでは見つからない、漏れや重複のあるロジックが蓄積することがあります。このスキルではリポジトリのインベントリを作成し、ダイジェストを複数に振り分けた後、人間をループに含めながらすべての境界を確認します。

呼び出し

/slice-and-spine-review [scope: slice names | seam ids | full]

デフォルトのスコープは full です。名前付きスコープ（スライス名またはシーム ID）を指定すると、フェーズ 2 の確認とフェーズ 3 のスパイン訪問は、一致するシームとユースケースに限定されます。ただし、フェーズ 0 のインベントリとマトリックスはリポジトリ全体を対象とするため、ランキングに十分なコンテキストが与えられます。

用語

• スライス — ドクトリン上の役割を持つ domains/* モジュールです。必ずしも domains という名前のディレクトリとは限りません。
• クラスト — 言語固有の形式で表されるスライスの公開シームです（エクスポートされた識別子、パッケージの __init__ サーフェス、インデックスモジュール、公開クラスのサーフェス、またはネイティブな可視性のない言語における位置上のルート）。詳しい根拠： https://cheeselord.dev/sliced-bread-architecture/reference/sliced-bread/ （リポジトリ内：[[architecture/crust-definition]]）。
• スパイン — app/use_cases とコンポジションルート（app/bootstrap）です。
• シーム — 境界をまたぐエッジで、次の3種類のいずれかです：スライス間（クラストのインポートまたはイベント）、スパインとスライス間、アダプターとポートのバインディングです。Feathers スタイルのテスト差し替えシームとは異なります。

フェーズ 0 — インベントリ

1. スライス（crust）、スパイン、およびそれらを横断するすべてのシームを列挙し、上記の 3 種類のエッジに分類します。

2. 呼び出し元グラフのコードインテリジェンス（エントリポイントからスパインを通ってスライスに至る依存関係のクロージャー／呼び出し階層）からホットパスを導出します。ホットパスは、シームのランキング（以下）、SeamDossiers（フェーズ 1）、およびスパインの訪問順序（フェーズ 3）に使用します。

3. スライスのリンクレベルマトリクスを作成します。すべてのスライスのペアについて、根拠とともに序数レベルを 1 つ割り当てます。

   レベル	意味
   L0	リンクなし
   L1	イベントでリンク
   L2	crust のインポート
   L3	複数シンボルのインポート
   L4	変更連動が活発

   レベルにかかわらず、各セルには指定された根拠の 3 要素（imports、co_change、hot_paths。references/formats.md に従う）を記録します。レベルの意味を説明する際、そのレベルを見分ける検出入力を本文中に記載してもかまいません（例：L1 のイベントリンク、L3 の複数のインポート済みシンボル）。ただし、その入力を独立した根拠フィールドにはしません。

   L4（変更連動が活発）は、高い変更連動スコアがある場合、またはインポート要件なしでホットパスがペアを横断する場合に該当します。この序数の段階は、L4 にインポートが必要であることを意味しません。

   スキーマは references/formats.md に固定し、ここではフィールドの形式を再記載しないでください。

4. 変更連動を優先してシームの巡回順をランキングします。シームを co_change の降順（主キー）で並べ、同値の場合は 0～1 に正規化した項目の合成値（調整可能）で順位を決めます。

   tiebreak = w_f * norm(fan_in) + w_d * depth_verdict_weight
            + w_h * norm(|hot_paths_crossing|)
   norm(x) = x / max(x over all seams)   # 0 when the max is 0
   

   • fan_in — 境界を横断する静的なファンイン数。すべてのシームにおける最大の fan_in で割り、[0,1] に正規化します。
   • depth_verdict_weight — [0,1]。下記の判定テーブルを参照してください。
   • |hot_paths_crossing| — SeamDossier の hot_paths_crossing 配列（ホットパス識別子の string[]）の長さ。すべてのシームにおける最大数で割り、[0,1] に正規化します。

   初期ウェイトは w_f=0.4, w_d=0.35, w_h=0.25 です。リポジトリに応じて調整し、その調整内容をセッションレポートに記録します。

   co_change は連続値のため、実際には合成値によって、co_change が同じ（通常はゼロ）シームが並べ替えられます。ウェイトが最も大きく影響するのは、一度も変更連動していない末尾部分です。

   depth_verdict_weight は、sliced-bread-depth の判定を、境界の問題を示す強さに応じて [0,1] に対応付けます（そのスキル独自の意味に従います）。シームには、両側のスライス判定ウェイトの大きい方を適用します。スパインやアダプター／ポートなどの非スライス側は 0 とします。判定は sliced-bread-depth の実行結果、または最新のレポートから取得します。深さレポートがない場合は、すべてのシームで depth_verdict_weight = 0 とし、下記の浅い Git 履歴に関する劣化ルールと同様に、その劣化をセッションレポートに記録します。

   判定	ウェイト
   extract	1.0
   narrow	0.75
   watch	0.5
   intent	0.25
   healthy	0

5. common/ のエッジは、変更連動によってフラグが立った場合に限り、巡回対象とします。すべての common/ インポートをデフォルトで巡回対象にしないでください。

6. 浅い Git 履歴の場合、ランキングはファンインのみを使ったものに劣化します。その旨をセッション出力（フェーズ 4）に明記してください。履歴の深さが不足していても、レビューを失敗させないでください。

フェーズ 1 — ファンアウト

人間とのセッションを開始する前に、呼び出しのスコープ内にあるファイルとテストのペアごとに、1 つずつサブエージェントを起動します。対象は、スコープ内のスライスのファイル（およびそのテスト）、スパイン、さらにスコープ内のスライスに接するすべてのシームの反対側のスライスです。シームは両側のドシエがそろって初めて判定できます。スコープが full の場合は、リポジトリ全体が対象です。 ハーネスで Workflow ツールが提供されている場合はそれを使用し、そうでなければ Agent ツールを使用します。

各サブエージェントは、固定されたスキーマに準拠する FileDigest を生成します。スキーマは references/formats.md にあります。内容は、公開されるサーフェス、使用されるサーフェス、テストから抽出した動作のアサーション、重複の疑いがある箇所です。テストのないファイルは、動作のアサーションの代わりに UNTESTED マーカーを付けます。実装を読んでアサーションを推測してはいけません。

FileDigest を集約します。

• スライスごとに SliceDossier — 外部向けサーフェス、内部ファイル、アサーションマップ、規模。
• シームごとに SeamDossier — スライス側については SliceDossier から導出し、スライスでない側については識別子と要約を簡潔に記載します。これにフェーズ 0 の共変更およびホットパスの根拠を加えます。

すべてのドシエには、作成元のコミットを記録します（古さのガード。セッション中に編集が行われた場合、そのパスにおける現在の HEAD より古いドシエは古いものとみなされ、黙って信頼せず、該当する停止地点の前に再構築する必要があります）。

すべてのスキーマは references/formats.md にあります。ドシエとプロンプトではこのパスを参照し、スキーマをここに重複して記載しないでください。

フェーズ 2 — シームウォーク

ガイド付きセッションで、ランク順にシームごとに 1 つの停止地点を設けます。

1. 停止カードを提示します。内容は、シーム ID、エッジの種類、リンクレベル（スライス間のシームのみ）、両側の要約（スライス側は SliceDossier の要約、スパインまたはアダプター／ポート側は識別子と 1 行の要約）、共変更およびホットパスの根拠、ドシエから見つかった候補です。

2. 人間は自由に質問できます。エージェントは、記憶や推測ではなく、ドシエと実行時のコード調査（検索、読み取り、呼び出し元のグラフ）に基づいて回答します。

3. 人間は停止地点ごとに、次の判定を 1 つだけ指定します。

   判定	意味
   pull-up	重複または漏出したロジックを上位の共有シームに移す
   push-down	ロジックをシームからスライス／スパインに移す
   rethink-seam	エッジの種類または方向自体が誤っている
   healthy	対応不要

4. 根拠とフォローアップを含む判定を記録し、ランク順で次のシームに進みます。

人間はいつでもウォークを終了できます。ウォークがどこで終了しても、訪問したシーム数と総数に基づくカバレッジをセッションレポートに記録します。

フェーズ 3 — スパインレビュー

app/use_cases をホットパス優先で確認し（確認順にはフェーズ 0 で導出したホットパスを使用）、続いてコンポジションルートを確認します。

• オーケストレーションのみの確認 — スライスに処理を委譲せず、インラインのドメインロジック（分岐するビジネスルール、計算、不変条件のチェック）を含むユースケースは、push-down の候補です。
• コンポジションルートの配線確認 — app/bootstrap はアダプターをポートとユースケースに接続します。そこで見つかったドメインロジックやアダプター固有の分岐は、アダプターまたは該当するスライスへの push-down 候補です。

スパインの指摘事項には、フェーズ 2 と同じ判定セットを適用し、同じセッションレポートに記録します。

フェーズ 4 — 締めくくり

1. セッションレポートを .cheese/slice-and-spine/<repo>/<date>.md に作成します： 訪問した停止地点、網羅範囲、判定、リンクレベルのマトリックス、および ランキングの劣化（履歴が浅い、重みを調整したなど）に関する注記を記載します。
2. 重大な判定（健全ではなく、格上げ、格下げ、境界の再検討）はすべて、 .hallouminate/wiki/ 配下の ADR に基づく Wiki ページにします。 リポジトリで最初に締めくくる際に、Wiki 独自の ADR 規約に照らして 正確な名前空間（decisions/ と architecture/ のどちらか）を確定し、 以降の実行で一貫するよう、その決定をセッションレポートに記載します。
3. 残りのフォローアップ作業は引き継ぎメニュー（/mold、/cook）として提示し、 未対応の指摘事項を黙って放置しないでください。

対象外

• 範囲を限定した差分に対するルール準拠のチェックではありません。その場合は sliced-bread-review を使用してください。
• 自律的な監査や課題の起票ではありません。その場合は sliced-bread-audit を使用してください。
• 深さやクラスト形状の評価ではありません。その場合は sliced-bread-depth を使用してください。