perimeter

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

ドメインの評価基準

1. 境界監査の観点

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

  Banned:   fetch("https://api.domain/orders") // Raw runtime bypass
  Required: appHttpClient.get("/orders")       // Sanctioned primitive with auth & telemetry
  

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. アーキテクチャ上のアンカー（内部ラッパー、承認済みクライアント、リゾルバー、基底インターフェイス）を調査し、境界の基準を確立します。

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

• ターン内実行（ファイル数が 10 未満、またはローカルなモジュール）：発見したアンカーに照らして、同じターン内で呼び出し箇所を直接監査します。
• サブエージェントへの分担（広範なコードベース、またはレイヤーをまたぐスコープ）：分割した範囲または呼び出し元が指定した予算に応じて規模を調整し、research サブエージェントを並行して起動します（役割：Perimeter Reviewer (<Slice>)）。対象スライスのディレクトリ、発見したアーキテクチャ上のアンカー、アーキテクチャ上の要となる条件の適格性ゲート、references/fitness-functions.md へのパス、および問題のあるコードの位置（file:///...#L<N>）を必須とする標準サブレポート仕様を渡します。

フェーズ 3：形式化とターン停止ゲート（集約）

1. 発見事項を標準出力仕様に統合し、根拠のないルールはセクション 3（除外済み）に移します（該当がない場合はセクション 3 を省略します）。
2. 境界の所有権またはホワイトリストの適用除外に未解決のトレードオフがある場合は、停止して検討します（/clarify 経由）。
3. レポートを会話ストリームに出力し、直ちにターンを停止します。