End-to-End Wiring 末端到達・貫通の検証 · diff
v0.1.0 to v0.1.0
2 added, 2 removed. Audit A to A.
---
id: 'e2e-wiring'
name: 'End-to-End Wiring 末端到達・貫通の検証'
description: '宣言した処理(計測 / 通知 / 保存 / 検証 / 例外通知)が起点から末端まで途切れず配線されているかを確認し、「実装したつもり」で経路が途中で止まっている欠落を検出する'
version: 0.1.0
category: midstream
phase: midstream
applyTo:
- '**/*.{ts,tsx,js,jsx,mjs,cjs,py,rb,go,php,java}'
tags: [wiring, end-to-end, correctness, integration, midstream]
severity: major
inputContext: [diff]
outputKind: [findings, questions]
modelHint: high-accuracy
dependencies: [code_search]
---
## Pattern declaration
Primary pattern: Reviewer
Secondary patterns: Inversion
Why: 宣言された処理の配線追跡はチェックリスト型だが、貫通すべき処理を含まない変更では実行を止めるゲートが必要。
## Goal / 目的
- ある処理が「宣言(意図)」されているのに、起点から末端まで**配線が途切れている**欠落を検出する。
- 「実装したつもり」で経路が途中で止まっているパターン(計測がセッション書き込み止まりで永続化されない、`validate()` が保存経路に未配線、例外を捕捉して silent skip)を可視化する。
## Non-goals / 扱わないこと
- - 個別関数の論理的正しさ(`rr-midstream-logic-torturing-001` の領域)。
- - caller 側の旧構造残骸(リファクタ後ドリフトは `rr-midstream-cross-file-leakage-001` の領域)。
+ - 個別関数の論理的正しさ(`logic-torturing` の領域)。
+ - caller 側の旧構造残骸(リファクタ後ドリフトは `cross-file-leakage` の領域)。
- テストの有無そのもの(テスト不足は test 系スキルの領域。本スキルは「本番経路の配線」を見る)。
## Pre-execution Gate / 実行前ゲート
このスキルは以下の条件がすべて満たされない限り `NO_REVIEW` を返す。
- [ ] 差分が、**新規に起点→末端の貫通経路を導入または変更**している(計測 / 通知 / 非同期 / 永続化 / 検証配線 / 例外通知 など複数層をまたぐ処理の新設・結線変更)。既存経路に無関係な単純変更(変数名変更・コメント・ログ文言・定数値の差し替えなど、貫通経路の新設・切断を伴わない変更)は対象外とする
- [ ] inputContext に diff が含まれ、`code_search`(grep)が利用可能である
ゲート不成立時の出力: `NO_REVIEW: e2e-wiring — 貫通処理の変更が検出されない`
## False-positive guards / 抑制条件
- 経路の末端側が差分外の場合は、**まず `code_search`(grep)で呼び出し先・末端の配線を確認した上でのみ**指摘する。grep で確認せず「差分内に末端が見えない」ことだけを根拠に「途切れている」と推測断定してはならない(推測断定は最も多い誤検出源)。grep で配線済みと確認できたら指摘しない。
- 末端の到達可否が grep でも確定できない場合は、`findings` で断定せず `questions` で確認する。
- 意図的に途中で止める設計(feature flag で後続を保留中など)が差分内に明記されている場合は抑制。
- ベストエフォートで欠落が許容される処理(デバッグログ等)は対象外。
## Rule / ルール
### 検出ロジック
1. **宣言の特定**: 差分から「何をする宣言か」を抽出する(計測する / 通知する / 保存する / 検証する / 例外を通知する など)。
2. **経路の追跡**: その宣言の起点(呼び出し箇所)から末端(送信完了 / 受信者 / DB 確定 / 監視到達 / 戻り値の利用)まで、各ホップが実際に配線されているかを追う。
3. **途切れの判定**: 次の典型断点を確認する。
- 計測・状態を**セッション / メモリに書いたが永続化・送信していない**
- `validate()` 等を**定義したが保存・実行経路に呼び出していない**
- 例外を `catch` して**通知・再送・再 throw のいずれもせず握り潰している**(silent skip)
- 非同期処理を**`await` / 完了確認せず**発火しっぱなし
4. **報告**: 起点と途切れた箇所を両方 `<file>:<line>` で示す。
### 制約
- 検出は最大 5 件。本番影響(データ欠落 / 通知不達 / 集計欠損)が大きいものを優先。
- 各指摘に「宣言」「起点」「途切れた箇所」「末端に到達しない影響」を必ず含める。
- 経路が差分から追えない場合は断定せず `questions` で確認する。
## Evidence / 根拠の取り方
- 宣言・起点・断点は必ず `<file>:<line>` に紐づけ、推測で経路を述べない。
- 「どこまで到達し、どこで止まるか」を入力→処理→末端の流れで具体的に示す。
## Output / 出力フォーマット
すべて日本語。
```text
(e2e-wiring):1: [要約] 末端に到達しない最も重大な処理は〈1文〉
<file>:<line>: [配線断点1] <タイトル>
宣言: <何をするはずか>(<起点 file>:<line>)
途切れ: <どこで止まるか>(<断点 file>:<line>)
影響: <データ欠落 / 通知不達 / 集計欠損 / 例外の不可視化>
Fix: <末端まで配線する最小修正(永続化呼び出し / 経路への結線 / 再throw・通知)>
```
## 評価指標(Evaluation)
- 合格基準: 宣言・起点・断点が `<file>:<line>` で示され、末端未到達の実害が具体的に説明されている。
- 不合格基準: 経路の推測、差分にない配線の断定、テスト不足やロジック正しさへの越境。
## 人間に返す条件(Human Handoff)
- 末端(外部システム・他サービス)への到達可否が環境依存で、コードからは判断できない場合。
- 途中で止める設計が意図的かどうかの判断が必要な場合。