ln-642-layer-boundary-auditor

パス： ファイルパス（references/、../ln-*）は、このスキルのディレクトリからの相対パスです。

レイヤー境界監査

タイプ： L3 ワーカー

アーキテクチャのレイヤー境界を監査し、違反を検出する L3 ワーカーです。

目的と範囲

• architecture.md を読み込み、プロジェクトのレイヤー構造を把握します
• レイヤー違反を検出します（インフラストラクチャレイヤー外の I/O コード）
• レイヤー間の整合性に関する問題を検出します：
  • トランザクション境界（コミット／ロールバックの所有者）
  • セッションの所有者（DI またはローカル）
• パターンの適用範囲を確認します（すべての HTTP 呼び出しがクライアント抽象化を使用していること）
• エラー処理の重複を検出します
• 違反の一覧をコーディネーターに返します

対象外（ln-628-concurrency-auditor の担当）：

• 非同期関数内のブロッキング I/O（async def 内での同期 open/read）
• Fire-and-forget タスク（エラーハンドラーのない create_task）

入力（ln-640 から）

- architecture_path: string    # Path to docs/architecture.md
- codebase_root: string        # Root directory to scan
- skip_violations: string[]    # Files to skip (legacy)
- output_dir: string           # e.g., ".hex-skills/runtime-artifacts/runs/{run_id}/audit-report"

# Domain-aware (optional, from coordinator)
- domain_mode: "global" | "domain-aware"   # Default: "global"
- current_domain: string                   # e.g., "users", "billing" (only if domain-aware)
- scan_path: string                        # e.g., "src/users/" (only if domain-aware)

domain_mode="domain-aware" の場合： すべての Grep/Glob 操作で codebase_root の代わりに scan_path を使用してください。すべての検出結果に domain フィールドを付けてください。

ワークフロー

必須の読み込み： 検出方法について references/two_layer_detection.md を読み込みます。 必須の読み込み： references/mcp_tool_preferences.md と references/mcp_integration_patterns.md を読み込みます。

参照情報、呼び出しパス、またはアーキテクチャの結合度が監査の質を大きく向上させる場合は、まず hex-graph を使用してください。利用可能な場合は、ローカルのコードや設定を読み込む際に、まず hex-line を使用してください。MCP が利用できない場合、未対応の場合、またはインデックス化されていない場合は、組み込みの Read/Grep/Glob/Bash を使って続行し、レポートに代替手段を明記してください。

フェーズ 1：アーキテクチャの把握

必須の読み込み： ../ln-640-pattern-evolution-auditor/references/layer_rules.md を読み込みます。アーキテクチャプリセット（フォールバック）、I/O パターンの境界ルール（フェーズ 2）、適用範囲の確認（フェーズ 4）、レイヤー間の整合性ルール（フェーズ 3）を使用してください。

Read docs/architecture.md

Extract from Section 4.2 (Top-Level Decomposition):
  - architecture_type: "Layered" | "Hexagonal" | "Clean" | "MVC" | etc.
  - layers: [{name, directories[], purpose}]

Extract from Section 5.3 (Infrastructure Layer Components):
  - infrastructure_components: [{name, responsibility}]

IF architecture.md not found:
  Use fallback presets from layer_rules.md

Build ruleset:
  FOR EACH layer:
    allowed_deps = layers that can be imported
    forbidden_deps = layers that cannot be imported

グラフによる高速化（利用可能な場合）： contextStore.graph_indexed が true の場合、または .hex-skills/codegraph/index.db が存在する場合：

• モジュールの結合度： analyze_architecture(path=scan_root, verbosity="full") を実行し、返された結合度メトリクスを使って、密結合しているレイヤーを特定します。
• レイヤー間の呼び出し： トランザクション／セッション関連の関数に対して find_references(symbol) を使い、レイヤーをまたいでコミット／ロールバックの所有者を追跡します。
• オーケストレーションの深さ： trace_paths(name="ServiceFn", file="...", path_kind="calls", direction="forward", depth=3, path=scan_root) を実行し、具体的なサービスシンボルを起点に、フラットなオーケストレーションの確認に必要なチェーンの深さを測定します。
• 粗すぎるセレクターやモジュールレベルのセレクターを使った trace_paths が空でも、そのレイヤーに問題がないとは判断できません。セレクターの範囲が広い場合は、inspect_symbol または grep／手動レビューに切り替えてください。
• グラフが利用できない場合は、以下の grep ベースの検出方法に切り替えてください。

フェーズ 2：レイヤー違反の検出

scan_root = scan_path IF domain_mode == "domain-aware" ELSE codebase_root

FOR EACH violation_type IN layer_rules.md I/O Pattern Boundary Rules:
  grep_pattern = violation_type.detection_grep
  forbidden_dirs = violation_type.forbidden_in

  matches = Grep(grep_pattern, scan_root, include="*.py,*.ts,*.js")

  FOR EACH match IN matches:
    IF match.path NOT IN skip_violations:
      IF any(forbidden IN match.path FOR forbidden IN forbidden_dirs):
        violations.append({
          type: "layer_violation",
          severity: "HIGH",
          pattern: violation_type.name,
          file: match.path,
          line: match.line,
          code: match.context,
          allowed_in: violation_type.allowed_in,
          suggestion: f"Move to {violation_type.allowed_in}"
        })

フェーズ 3：レイヤー間の整合性確認

3.1 トランザクション境界の違反

内容： 一貫しないレイヤー（リポジトリ、サービス、API）で commit()/rollback() が呼び出されています。

検出：

repo_commits = Grep("\.commit\(\)|\.rollback\(\)", "**/repositories/**/*.py")
service_commits = Grep("\.commit\(\)|\.rollback\(\)", "**/services/**/*.py")
api_commits = Grep("\.commit\(\)|\.rollback\(\)", "**/api/**/*.py")

layers_with_commits = count([repo_commits, service_commits, api_commits].filter(len > 0))

安全なパターン（無視）：

• 同じコンテキストにコメント「# best-effort telemetry」がある
• ファイル名が _callbacks.py で終わる（進捗通知）
• # UoW boundary コメントが明示されている

違反ルール：

条件	重大度	問題
layers_with_commits >= 3	CRITICAL	すべてのレイヤーにわたって UoW の所有者が混在しています
repo + api commits	HIGH	トランザクション制御がサービスレイヤーを迂回しています
repo + service commits	HIGH	UoW の所有者（repo または service）が曖昧です
service + api commits	MEDIUM	トランザクション制御がサービスと API にまたがっています

例外： 補償アクションを明示した Saga パターン／分散トランザクションの場合は、CRITICAL を MEDIUM に引き下げます。// architecture decision または ADR に UoW 境界が記録されている場合は、スキップします。

推奨事項： UoW の所有者を 1 つのレイヤー（サービスレイヤーを推奨）に決め、他のレイヤーから commit() を削除します。

作業量： L（アーキテクチャ上の決定とリファクタリングが必要）

3.2 セッション所有権違反

内容： 同じ呼び出しチェーン内で、DI による注入とローカルで作成したセッションが混在しています。

検出：

di_session = Grep("Depends\(get_session\)|Depends\(get_db\)", "**/api/**/*.py")
local_session = Grep("AsyncSessionLocal\(\)|async_sessionmaker", "**/services/**/*.py")
local_in_repo = Grep("AsyncSessionLocal\(\)", "**/repositories/**/*.py")

違反ルール：

条件	重大度	問題
同じモジュール内に di_session と local_in_repo がある	HIGH	API が別のセッションを注入している一方で、リポジトリが独自のセッションを作成しています
DI ベースのリポジトリを呼び出すサービスで local_session を使用している	MEDIUM	呼び出しチェーン内でセッションが一致していません

推奨事項： DI を一貫して使用するか、ローカルセッションを一貫して使用してください。例外（テレメトリーなど）は文書化してください。

工数： M

3.3 フラットなオーケストレーションの違反

内容： サービス層の関数が別のサービスを呼び出し、そのサービスがさらに別のサービスを呼び出す、深いオーケストレーションチェーンです。

検出： 必読： references/ai_ready_architecture.md を読み込み、サービスのインポートをマッピングしてチェーンの深さを確認してください。

違反ルール：

条件	重大度	問題
サービスチェーンが 3 以上（A->B->C->D）	HIGH	オーケストレーションが深すぎます
サービスチェーンが 2（A->B->C）	MEDIUM	フラット化を検討してください

推奨事項： すべてのサービスを同じ階層で呼び出すオーケストレーターを抽出してください。各サービスは終端になります。

工数： L

---

フェーズ 4：パターンのカバレッジを確認

# HTTP Client Coverage
all_http_calls = Grep("httpx\\.|aiohttp\\.|requests\\.", codebase_root)
abstracted_calls = Grep("client\\.(get|post|put|delete)", infrastructure_dirs)

IF len(all_http_calls) > 0:
  coverage = len(abstracted_calls) / len(all_http_calls) * 100
  IF coverage < 90%:
    violations.append({
      type: "low_coverage",
      severity: "MEDIUM",
      pattern: "HTTP Client Abstraction",
      coverage: coverage,
      uncovered_files: files with direct calls outside infrastructure
    })

# Error Handling Duplication
http_error_handlers = Grep("except\\s+(httpx\\.|aiohttp\\.|requests\\.)", codebase_root)
unique_files = set(f.path for f in http_error_handlers)

IF len(unique_files) > 2:
  violations.append({
    type: "duplication",
    severity: "MEDIUM",
    pattern: "HTTP Error Handling",
    files: list(unique_files),
    suggestion: "Centralize in infrastructure layer"
  })

フェーズ 5：スコアを計算

必読： references/audit_worker_core_contract.md と references/audit_scoring.md を読み込んでください。

フェーズ 6：レポートを作成

必読： references/audit_worker_core_contract.md と references/templates/audit_worker_report_template.md を読み込んでください。

references/audit_summary_contract.md に従って JSON サマリーを作成してください。マネージドモードでは呼び出し元が runId と summaryArtifactPath の両方を渡します。スタンドアロンモードでは、ワーカーが共有コントラクトに従って独自の実行スコープ付きアーティファクトパスを生成します。

# Build markdown report in memory with:
# - AUDIT-META (standard penalty-based: score, counts)
# - Checks table (io_isolation, http_abstraction, error_centralization, transaction_boundary, session_ownership)
# - Findings table (violations sorted by severity)
# - DATA-EXTENDED: {architecture, coverage}

IF domain_mode == "domain-aware":
  Write to {output_dir}/642-layer-boundary-{current_domain}.md
ELSE:
  Write to {output_dir}/642-layer-boundary.md

フェーズ 7：サマリーを返す

Report written: .hex-skills/runtime-artifacts/runs/{run_id}/audit-report/642-layer-boundary-users.md
Score: 4.5/10 | Issues: 8 (C:1 H:3 M:4 L:0)

重要なルール

必読： references/audit_worker_core_contract.md を読み込んでください。

• 最初に architecture.md を読む - アーキテクチャの種類を決めつけないでください
• 違反リストをスキップする - 段階的な修正対象としてマークされたレガシーファイルを尊重してください
• ファイル + 行 + コード - コンテキストとともに正確な場所を必ず示してください
• 実行可能な提案 - コードをどこに移動すべきかを必ず伝えてください
• 誤検出を避ける - 部分文字列だけでなく、パスに禁止ディレクトリが含まれていることを確認してください

完了の定義

必読： references/audit_worker_core_contract.md を読み込んでください。

• docs/architecture.md からアーキテクチャを特定した（またはフォールバックを使用した）
• layer_rules.md に記載されたすべての違反タイプを確認した
• レイヤー間の一貫性を確認した：
  • トランザクション境界を分析した（コミット／ロールバックの分布）
  • セッション所有権を分析した（DI とローカル）
• HTTP 抽象化 + 2 つの一貫性メトリクスのカバレッジを計算した
• 重大度、場所、提案を含む違反リストを作成した
• ドメインを考慮する場合：すべての Grep を scan_path に限定し、検出結果にドメインのタグを付けた
• {output_dir}/642-layer-boundary[-{domain}].md にレポートを作成した（単一の Write 呼び出しでアトミックに書き込み）
• コントラクトに従ってサマリーを作成した

参照ファイル

• レイヤールール：../ln-640-pattern-evolution-auditor/references/layer_rules.md
• スコアリングへの影響：../ln-640-pattern-evolution-auditor/references/scoring_rules.md

---

バージョン： 2.1.0 最終更新日： 2026-02-08