perimeter

perimeter — アーキテクチャ境界とバイパスの検出エンジン

ドメイン評価基準

1. 境界監査の観点

• 承認済みプリミティブと生のバイパス（水平）：I/O、ネットワーククライアント、リソース、ライフサイクルを管理する内部ラッパーを特定し、それらを迂回して生のランタイム API を呼び出している箇所にフラグを立てます。
• レイヤーと依存関係の方向性（垂直）：アーキテクチャレイヤー（Domain、App、Infra、UI）をまたぐインポートグラフを追跡し、逆向きのインポートや境界を越えたインポートにフラグを立てます。
• リソースとサンドボックスの衛生状態：ストレージパス、並行処理プール、メモリバッファーを監査し、基点のないファイルシステムアクセスや、スロットリングされていないリソースにフラグを立てます。

2. 制約の適格性判定ゲート

候補となる制約は、以下の 3 条件に厳密に照らして適格性を判定します。

1. 既存の承認済みプリミティブ：コードベースに、境界に対処する内部ラッパー、基底クラス、または標準的なパスが定義されています。
2. 実証されたバイパスの証拠：境界に違反して生の API を直接呼び出している、少なくとも 1 つの有効な呼び出し箇所があります。
3. 定量化可能な障害リスク：バイパスによって、アーキテクチャの逸脱、リソースリーク、メモリ枯渇、またはセキュリティ上の露出が生じます。

• 対象外の境界：見た目のスタイル、単純なユーティリティ（Math.*、コレクション）、または有効なプリミティブに裏付けられていない推測的なルールについて、制約の宣言を禁止します。

標準出力契約

# Perimeter Report: <Target Subsystem / Scope>

## 1. Executive Verdict
- **Target Inspected**: `<directory_or_package>`
- **Verdict**: <HARDENED | PARTIAL | UNPROTECTED> (<N> active boundaries)
- **Primary Risk**: <Single-sentence technical judgment on highest boundary exposure>

## 2. Qualified Boundary Declarations
*(If HARDENED: 'All architectural boundaries are enforced by active test suites; zero raw bypasses detected.')*

### Boundary: <Constraint Name, e.g., Direct Network Client Bypass>
- **Offending Evidence**: [<file>#L<N>](file:///path/to/file#L<N>) ── <Bypass snippet or call site>
- **Failure Risk**: <Concrete risk: memory leak / auth bypass / architectural drift>
- **Rule**: Required: `<Sanctioned Primitive>` ── Banned: `<Forbidden Raw API>`
- **Enforcement**: Tier: `<Arch Unit Test | AST Linter | Script Guard>` | Whitelist: `<Exempt files | 'None'>`

## 3. Disqualified Invariants (Pruned) *(omit if no candidate patterns pruned)*
- **[PRUNED] <Candidate Pattern>**: <Reason for rejection, e.g., No existing codebase primitive / Trivial style issue>

ルーティング

• 適格な境界について具体的な実装計画が必要な場合 →（/changeset 経由）。
• 境界テストに証拠に基づく変更セットと承認済みの実行範囲がある場合 →（/forge 経由）。
• 境界の所有権、ホワイトリストの例外、またはアーキテクチャ上のトレードオフについて人間の判断が必要な場合 →（/clarify 経由）。

実行プロトコル

フェーズ 1：マクロアンカーの特定

1. 対象のディレクトリまたはサブシステムを取り込みます。
2. シンボル検索ツールとファイル検索ツールを使用して、上位レベルのアーキテクチャアンカー（内部ラッパー、承認済みクライアント、リゾルバー、基底インターフェース）を調査します。
3. 後続の調査の基盤となる、根拠のあるアンカーのコンテキストを確立します。

フェーズ 2：規模に応じた境界監査

1. 対象範囲の規模を評価します。
   • ターン内実行（10 ファイル未満、または局所的なモジュール）：発見したアンカーに照らして、ターン内に呼び出し箇所を直接監査します。
   • サブエージェントへの分担（広範なコードベース、または複数レイヤーにまたがる範囲）：1～3 個の research サブエージェント（役割：Perimeter Reviewer (<Slice>)）を起動します。それぞれに以下を提供します。
     • 対象の範囲のディレクトリ。
     • フェーズ 1 で発見したアーキテクチャアンカー。
     • 制約の適格性判定ゲートと、references/fitness-functions.md へのパス。
     • 問題のあるコードの参照先（file:///...#L<N>）を必須とする、標準のサブレポート契約。

フェーズ 3：明文化とターン停止ゲート（結果の統合）

1. 調査結果を標準出力契約にまとめ、根拠のないルールをセクション 3（除外）に移します（該当するルールがなければセクション 3 は省略します）。
2. 境界の所有権またはホワイトリストの免除に未解決のトレードオフがある場合は、停止して協議します（/clarify 経由）。
3. レポートを会話ストリームに出力し、直ちにターンを終了します。