feat(hooks): カスタムリンターエンジンの導入

[aloekun]

Summary

• hooks-post-tool-linter に設定駆動型カスタムリントルールエンジンを追加
• custom-lint-rules.toml でプロジェクト固有ルールを定義可能に（Rustリビルド不要）
• 初期ルールとして no-console-log を追加（severity: error）
• 最小限の Logger クラスを実装（console.log の置換先、内部は console.info 等を使用）
• ADR-007: カスタムリンターの正規表現層/AST層の線引き基準を文書化

Architecture

PostToolUse hook 実行フロー:
  第1層: カスタムルール (正規表現, ~1ms) ← 今回追加
    └─ custom-lint-rules.toml のルールでリテラルマッチ
    └─ 構造化 JSON で additionalContext にフィードバック
  第2層: 外部ツール (biome/oxlint, ~10ms) ← 既存

Files changed

ファイル	変更内容
.claude/custom-lint-rules.toml	カスタムルール定義（no-console-log）
.claude/hooks-config.toml	カスタムリンターセクションのコメント追加
.claude/hooks-post-tool-linter/Cargo.toml	regex クレート追加
.claude/hooks-post-tool-linter/src/main.rs	カスタムルールエンジン + ユニットテスト
CLAUDE.md	ADR-007 へのリンク追加
docs/adr/adr-007-custom-linter-layer-boundary.md	正規表現/AST層の判断基準
src/logger.ts	最小限の Logger クラス

Test plan

• cargo test — カスタムルールエンジンのユニットテスト全通過
• pnpm build:hooks — exe ビルド成功
• 手動テスト: console.log を含む .ts ファイルで構造化 JSON フィードバックを確認
• logger.ts がカスタムリンターに引っかからないことを確認（console.info 使用）
• レビュー: custom-lint-rules.toml のルール定義が適切か

🤖 Generated with Claude Code

Summary by CodeRabbit

リリースノート

• New Features

  • レベル別ロギング（debug/info/warn/error）を追加しました。
  • プロジェクト固有のカスタムリンターを導入し、console.log 等の検出と削除／logger への置換案を表示します。

• Documentation

  • カスタムリンターの設計判断をまとめた ADR（ADR-007）を追加しました。

• Tests

  • カスタムリンターの包括的なテストを追加しました。

[coderabbitai]

📝 Walkthrough

Walkthrough

TOMLで定義した正規表現ベースのカスタムリンタールールを読み込み、事前リンターステージ（Rust実行バイナリ）でファイルを走査してJSON形式の違反を出力する機能を追加。併せてTypeScriptの簡易Loggerモジュールを追加。

Changes

Cohort / File(s)	Summary
Custom lint config & hooks /.claude/custom-lint-rules.toml, /.claude/hooks-config.toml	プロジェクト固有の正規表現ルール定義ファイルを追加。hooks設定に注釈を挿入してrulesファイルの位置と制約を明記。
Lint runner deps /.claude/hooks-post-tool-linter/Cargo.toml	regex = "1.10" を依存に追加、tempfile = "3" をdev-dependenciesに追加。
Custom lint implementation /.claude/hooks-post-tool-linter/src/main.rs	事前カスタムリンターステージを導入：実行ファイル位置からTOMLを読み込み、拡張子フィルタ（大文字小文字を無視）、正規表現マッチ、構造化JSON違反生成、フィードバック送信を実装。多数のユニットテストを追加。
Logger module src/logger.ts	LogLevel型、Loggerクラス（閾値判定）およびデフォルトsingleton logger を追加（debug/info/warn/error）。
Docs & ADR CLAUDE.md, docs/adr/adr-007-custom-linter-layer-boundary.md	ADR-007を追加し、正規表現層とAST層の切り分け基準と運用指針を記載。

Sequence Diagram

sequenceDiagram
    autonumber
    actor User
    participant Linter as "hooks-post-tool-linter\n(Rust exe)"
    participant Config as "custom-lint-rules.toml"
    participant File as "Target File"
    participant Feedback as "Feedback Output"

    User->>Linter: スキャン起動
    Linter->>Config: TOML読み込み/パース
    Config-->>Linter: ルール集合(regex/拡張子/メッセージ/修正)
    loop 各対象ファイル
        Linter->>File: 行ごと読み取り
        File-->>Linter: 行内容
        Linter->>Linter: 正規表現マッチ判定（拡張子チェック）
        alt マッチ
            Linter->>Linter: 違反オブジェクト生成(JSON)
        end
    end
    Linter->>Feedback: `[custom-lint]` プレフィックス付きフィードバック送信
    Feedback-->>User: 構造化違反情報

Loading

Estimated Code Review Effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• feat(hooks): 設定駆動型アーキテクチャに移行し配布自動化を実装 #1 — 同じフックバイナリ（.claude/hooks-post-tool-linter）とhooks設定を変更しており、設定駆動のTOMLバックエンド実装と重なりがあるため直接関連。

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	PR のタイトルは「feat(hooks): カスタムリンターエンジンの導入」で、実装の中核である hooks-post-tool-linter へのカスタムリントルールエンジンの追加という主な変更を正確に反映しており、簡潔で具体的です。
Docstring Coverage	✅ Passed	Docstring coverage is 92.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (1)

docs/adr/adr-007-custom-linter-layer-boundary.md (1)

24-35: フェンスドコードブロックに言語指定を追加することを推奨

静的解析ツールが指摘しているように、フェンスドコードブロックには言語を指定することがベストプラクティスです。フローチャートなので text または plaintext を指定できます。

📝 修正案

-```
+```text
 Q1. 違反は 1 行だけ見て判定できるか？
     └─ No → AST 層

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/adr/adr-007-custom-linter-layer-boundary.md` around lines 24 - 35, Add a
language identifier to the fenced code block that contains the flowchart (the
block starting with ``` and lines like "Q1. 違反は 1 行だけ見て判定できるか？" / "Q2.
コメント・文字列リテラル内の誤検出が問題になるか？" / "Q3. パターンはリテラル文字列のマッチのみで表現できるか？") — change the
opening fence from ``` to ```text (or ```plaintext) so the code block is
explicitly annotated for the static analysis tool and rendering.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@docs/adr/adr-007-custom-linter-layer-boundary.md`:
- Around line 24-35: Add a language identifier to the fenced code block that
contains the flowchart (the block starting with ``` and lines like "Q1. 違反は 1
行だけ見て判定できるか？" / "Q2. コメント・文字列リテラル内の誤検出が問題になるか？" / "Q3.
パターンはリテラル文字列のマッチのみで表現できるか？") — change the opening fence from ``` to ```text (or
```plaintext) so the code block is explicitly annotated for the static analysis
tool and rendering.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: ae8c74fb-6a89-4909-bd5e-4db83c7cc76f

📥 Commits

Reviewing files that changed from the base of the PR and between 1051b7b and f3b9f29.

⛔ Files ignored due to path filters (1)

• .claude/hooks-post-tool-linter/Cargo.lock is excluded by !**/*.lock

📒 Files selected for processing (7)

• .claude/custom-lint-rules.toml
• .claude/hooks-config.toml
• .claude/hooks-post-tool-linter/Cargo.toml
• .claude/hooks-post-tool-linter/src/main.rs
• CLAUDE.md
• docs/adr/adr-007-custom-linter-layer-boundary.md
• src/logger.ts

[coderabbitai]

🧹 Nitpick comments (3)

.claude/hooks-post-tool-linter/src/main.rs (3)

308-314: パフォーマンス: 正規表現の毎回コンパイル

run_custom_rulesが呼ばれるたびに正規表現をコンパイルしています。ADR-007で目標とされている ~1ms の処理時間を維持するため、ルール数が増えた場合はonce_cellやlazy_staticを使用してコンパイル済み正規表現をキャッシュすることを検討してください。

現時点ではルール数が少ないため即座の対応は不要ですが、将来の拡張時に考慮すべき点です。

♻️ キャッシュを使用した最適化案（参考）

use once_cell::sync::Lazy;
use std::collections::HashMap;
use std::sync::RwLock;

static COMPILED_REGEXES: Lazy<RwLock<HashMap<String, Regex>>> = 
    Lazy::new(|| RwLock::new(HashMap::new()));

fn get_or_compile_regex(pattern: &str) -> Option<Regex> {
    // Check cache first
    if let Ok(cache) = COMPILED_REGEXES.read() {
        if let Some(re) = cache.get(pattern) {
            return Some(re.clone());
        }
    }
    // Compile and cache
    match Regex::new(pattern) {
        Ok(re) => {
            if let Ok(mut cache) = COMPILED_REGEXES.write() {
                cache.insert(pattern.to_string(), re.clone());
            }
            Some(re)
        }
        Err(_) => None,
    }
}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.claude/hooks-post-tool-linter/src/main.rs around lines 308 - 314,
run_custom_rules currently calls Regex::new(&rule.pattern) for every rule
invocation which recompiles regexes on each run; replace that with a cached
lookup so compiled Regex instances are reused (e.g. add a static cache using
once_cell::sync::Lazy or lazy_static and a RwLock/Mutex-protected HashMap keyed
by rule.pattern). Implement a helper like get_or_compile_regex(pattern: &str)
that returns a cloned compiled Regex from the cache or compiles and inserts it
on miss, and use that helper in place of direct Regex::new(&rule.pattern) inside
run_custom_rules to avoid repeated compilation and improve performance.

---

639-663: テストの堅牢性: 一時ディレクトリ名の衝突可能性

テストで固定名の一時ディレクトリ（例: custom_lint_test_console_log）を使用しています。cargo testはデフォルトでスレッドプールを使用するため、並列実行時に競合する可能性があります。

tempfileクレートを使用するか、ユニークなサフィックスを追加することで、より堅牢になります。

♻️ tempfileクレートを使用した改善案

Cargo.tomlの[dev-dependencies]に追加:

tempfile = "3"

テストコードの例:

 #[test]
 fn run_custom_rules_detects_console_log() {
     use std::io::Write;
-    let dir = std::env::temp_dir().join("custom_lint_test_console_log");
-    let _ = std::fs::create_dir_all(&dir);
+    let dir = tempfile::tempdir().unwrap();
-    let file = dir.join("test.ts");
+    let file = dir.path().join("test.ts");
     {
         let mut f = std::fs::File::create(&file).unwrap();
         writeln!(f, "const x = 1;").unwrap();
         writeln!(f, "console.log('debug');").unwrap();
         writeln!(f, "const y = 2;").unwrap();
     }
     // ... test logic ...
-    let _ = std::fs::remove_dir_all(&dir);
+    // tempdir automatically cleaned up on drop
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.claude/hooks-post-tool-linter/src/main.rs around lines 639 - 663, Replace
the fixed temp directory used in the test run_custom_rules_detects_console_log
with a unique temporary directory from the tempfile crate: add tempfile = "3"
under [dev-dependencies] in Cargo.toml, create a TempDir via tempfile::tempdir()
inside the test and write the test.ts file into tempdir.path(), and pass that
file path to run_custom_rules; remove manual cleanup (remove_dir_all) since
TempDir will auto-delete. Ensure you update references to dir, file, and any
uses of std::env::temp_dir() so the test uses the TempDir API.

---

294-346: 違反数の上限がない点について

外部ツールの診断出力は20行に制限されていますが（251行目）、カスタムルールの違反には上限がありません。大量の違反がある場合、フィードバックが非常に大きくなる可能性があります。

現段階では問題にならないと思いますが、将来的に違反数の上限を設けることを検討してもよいかもしれません。

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.claude/hooks-post-tool-linter/src/main.rs around lines 294 - 346,
run_custom_rules currently returns an unbounded Vec<String> of violations; limit
its output to the same cap used for external diagnostics (use the existing
MAX_DIAGNOSTIC_LINES constant if present, or introduce a constant like
MAX_CUSTOM_VIOLATIONS) by truncating the violations before returning. Locate the
function run_custom_rules and after collecting violations (or during push)
ensure you only keep up to the max (e.g., violations.truncate(MAX); or return
violations.into_iter().take(MAX).collect()), and prefer reusing the existing
MAX_DIAGNOSTIC_LINES symbol to keep behavior consistent.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In @.claude/hooks-post-tool-linter/src/main.rs:
- Around line 308-314: run_custom_rules currently calls
Regex::new(&rule.pattern) for every rule invocation which recompiles regexes on
each run; replace that with a cached lookup so compiled Regex instances are
reused (e.g. add a static cache using once_cell::sync::Lazy or lazy_static and a
RwLock/Mutex-protected HashMap keyed by rule.pattern). Implement a helper like
get_or_compile_regex(pattern: &str) that returns a cloned compiled Regex from
the cache or compiles and inserts it on miss, and use that helper in place of
direct Regex::new(&rule.pattern) inside run_custom_rules to avoid repeated
compilation and improve performance.
- Around line 639-663: Replace the fixed temp directory used in the test
run_custom_rules_detects_console_log with a unique temporary directory from the
tempfile crate: add tempfile = "3" under [dev-dependencies] in Cargo.toml,
create a TempDir via tempfile::tempdir() inside the test and write the test.ts
file into tempdir.path(), and pass that file path to run_custom_rules; remove
manual cleanup (remove_dir_all) since TempDir will auto-delete. Ensure you
update references to dir, file, and any uses of std::env::temp_dir() so the test
uses the TempDir API.
- Around line 294-346: run_custom_rules currently returns an unbounded
Vec<String> of violations; limit its output to the same cap used for external
diagnostics (use the existing MAX_DIAGNOSTIC_LINES constant if present, or
introduce a constant like MAX_CUSTOM_VIOLATIONS) by truncating the violations
before returning. Locate the function run_custom_rules and after collecting
violations (or during push) ensure you only keep up to the max (e.g.,
violations.truncate(MAX); or return violations.into_iter().take(MAX).collect()),
and prefer reusing the existing MAX_DIAGNOSTIC_LINES symbol to keep behavior
consistent.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 4858db1e-f028-4b49-8237-7a813a49570a

📥 Commits

Reviewing files that changed from the base of the PR and between f3b9f29 and b5b785d.

⛔ Files ignored due to path filters (1)

• .claude/hooks-post-tool-linter/Cargo.lock is excluded by !**/*.lock

📒 Files selected for processing (7)

• .claude/custom-lint-rules.toml
• .claude/hooks-config.toml
• .claude/hooks-post-tool-linter/Cargo.toml
• .claude/hooks-post-tool-linter/src/main.rs
• CLAUDE.md
• docs/adr/adr-007-custom-linter-layer-boundary.md
• src/logger.ts

✅ Files skipped from review due to trivial changes (5)

• CLAUDE.md
• .claude/hooks-config.toml
• .claude/custom-lint-rules.toml
• .claude/hooks-post-tool-linter/Cargo.toml
• docs/adr/adr-007-custom-linter-layer-boundary.md

🚧 Files skipped from review as they are similar to previous changes (1)

• src/logger.ts

[coderabbitai]

🧹 Nitpick comments (1)

src/logger.ts (1)

57-57: 型専用エクスポートは export type に分離してください。

LogLevel は型専用（行10で定義）のため、export { Logger, LogLevel } の形式は TypeScript の isolatedModules や verbatimModuleSyntax 設定を有効化した場合に問題となる可能性があります。値と型を分離することは TypeScript の推奨ベストプラクティスです。

🔧 提案差分

 export const logger = new Logger();
-export { Logger, LogLevel };
+export { Logger };
+export type { LogLevel };

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/logger.ts` at line 57, 現在の export { Logger, LogLevel } は LogLevel
が型専用のため問題になる可能性があるので、値エクスポートと型エクスポートを分離してください：残すべき値のシンボル（Logger）を通常の export
として、型専用のシンボル（LogLevel）を export type を使ってエクスポートするように修正し、該当するエクスポート文（Logger と
LogLevel を扱っている箇所）を置き換えてください。

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@src/logger.ts`:
- Line 57: 現在の export { Logger, LogLevel } は LogLevel
が型専用のため問題になる可能性があるので、値エクスポートと型エクスポートを分離してください：残すべき値のシンボル（Logger）を通常の export
として、型専用のシンボル（LogLevel）を export type を使ってエクスポートするように修正し、該当するエクスポート文（Logger と
LogLevel を扱っている箇所）を置き換えてください。

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: fb7a6945-eeda-4ded-b9fa-3537cf6972d6

📥 Commits

Reviewing files that changed from the base of the PR and between b5b785d and ef7bda8.

⛔ Files ignored due to path filters (1)

• .claude/hooks-post-tool-linter/Cargo.lock is excluded by !**/*.lock

📒 Files selected for processing (7)

• .claude/custom-lint-rules.toml
• .claude/hooks-config.toml
• .claude/hooks-post-tool-linter/Cargo.toml
• .claude/hooks-post-tool-linter/src/main.rs
• CLAUDE.md
• docs/adr/adr-007-custom-linter-layer-boundary.md
• src/logger.ts

✅ Files skipped from review due to trivial changes (5)

• CLAUDE.md
• .claude/hooks-post-tool-linter/Cargo.toml
• .claude/hooks-config.toml
• .claude/custom-lint-rules.toml
• docs/adr/adr-007-custom-linter-layer-boundary.md

🚧 Files skipped from review as they are similar to previous changes (1)

• .claude/hooks-post-tool-linter/src/main.rs