Skip to content

Commit e5f1516

Browse files
T3pp31T3pp31
committed
add
1 parent d9bd481 commit e5f1516

7 files changed

Lines changed: 365 additions & 4 deletions

File tree

‎.claude/rules/CODES_RULE.md‎

Lines changed: 0 additions & 4 deletions
This file was deleted.

‎.claude/rules/GIT_CI.md‎

Lines changed: 70 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,70 @@
1+
# Git / CI 規約
2+
3+
## ブランチ戦略
4+
5+
| ブランチ | 用途 | 命名例 |
6+
|---------|------|--------|
7+
| `main` | 安定版。直接 push 禁止、PR 経由でマージ | — |
8+
| `feat/{name}` | 新機能開発 | `feat/binary-viewer` |
9+
| `fix/{name}` | バグ修正 | `fix/npcap-dialog-show-link` |
10+
| `refactor/{name}` | リファクタリング | `refactor/remove-npcap-from-lanscan` |
11+
| `test/{name}` | テスト追加・修正 | `test/port-scan-validation` |
12+
| `docs/{name}` | ドキュメント更新 | `docs/update-readme` |
13+
14+
## コミットメッセージ
15+
16+
Conventional Commits 形式を使用すること:
17+
18+
| プレフィックス | 用途 | 例 |
19+
|-------------|------|-----|
20+
| `feat:` | 新機能 | `feat: add binary viewer page` |
21+
| `fix:` | バグ修正 | `fix: NpcapDialogのDownloadボタンをリンク表示に変更` |
22+
| `refactor:` | リファクタリング | `refactor: LanScanPageから不要なNpcapチェックを削除` |
23+
| `test:` | テスト追加・修正 | `test: add NpcapDialog component tests` |
24+
| `docs:` | ドキュメント | `docs: update cross-platform rules` |
25+
| `ci:` | CI/CD 設定 | `ci: add macOS build support` |
26+
| `chore:` | その他雑務 | `chore: update dependencies` |
27+
28+
- 日本語・英語どちらでも可。ただし1コミット内で混在させないこと
29+
- 本文は変更の「なぜ」を記述すること
30+
31+
## プルリクエスト
32+
33+
- PR タイトルはコミットメッセージと同じ Conventional Commits 形式
34+
- PR 本文に変更の概要と影響範囲を記載すること
35+
- セキュリティ関連の変更（新しいネットワーク機能、権限変更）は明示的にレビューを依頼すること
36+
37+
## リリース（CI/CD）
38+
39+
### トリガー
40+
41+
- `v*` タグの push で `build-release.yml` が起動
42+
43+
### ビルド対象
44+
45+
| OS | ランナー |
46+
|----|---------|
47+
| Linux | ubuntu-22.04 |
48+
| macOS | macos-latest |
49+
| Windows | windows-latest |
50+
51+
### バージョニング
52+
53+
- セマンティックバージョニング: `v{MAJOR}.{MINOR}.{PATCH}`
54+
- リリースは Draft 状態で作成され、手動で公開すること
55+
56+
### タグ push 前の確認事項
57+
58+
- [ ] `src-tauri/Cargo.toml` の `version` を更新済み
59+
- [ ] `package.json` の `version` を更新済み
60+
- [ ] `npm run build` がエラーなく通ること
61+
- [ ] フロントエンドテスト（`npx vitest run`）が全パス
62+
- [ ] Rust テスト（`cargo test`）が全パス
63+
64+
### CI 環境の依存関係
65+
66+
| OS | 必要な依存 |
67+
|----|----------|
68+
| Linux | `libwebkit2gtk-4.1-dev`, `libpcap-dev`, `patchelf` 等 |
69+
| macOS | `libpcap`（brew） |
70+
| Windows | Npcap SDK（CI で自動ダウンロード） |

‎.claude/rules/RUST_CONVENTIONS.md‎

Lines changed: 56 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,56 @@
1+
# Rust コーディング規約
2+
3+
本プロジェクトの Rust コード（`src-tauri/src/`）に適用する規約。
4+
5+
## エラーハンドリング
6+
7+
- すべてのエラーは `error.rs` の `AppError` 列挙型に集約すること
8+
- 新機能追加時は `AppError` にバリアントを追加し、`#[error("...")]` で人間可読なメッセージを付与すること
9+
- コマンド関数の戻り値は `Result<T, AppError>` を使用すること（`CommandResult<T>` エイリアス可）
10+
- `unwrap()` / `expect()` は本番コードで使用禁止。テストコードでのみ許可
11+
- 外部クレートのエラーは `map_err` で `AppError` に変換すること
12+
- `#[from]` 自動変換は `std::io::Error` など汎用的なもののみに限定
13+
14+
## モジュール構造
15+
16+
| レイヤー | ディレクトリ | 責務 |
17+
|---------|------------|------|
18+
| Command | `commands/` | `#[tauri::command]` 関数。入力バリデーションと実装レイヤーへの委譲のみ |
19+
| 実装 | `network/` | ネットワーク処理ロジック。Tauri依存は `Window`（イベント発行用）のみ許可 |
20+
| ユーティリティ | `utils/` | ドメイン非依存の汎用処理 |
21+
| 設定 | `config.rs` | TOML設定ファイルの読み込みと `AppConfig` 構造体の管理 |
22+
| エラー | `error.rs` | カスタムエラー型 `AppError` の定義 |
23+
24+
- 各ディレクトリには `mod.rs` を配置し、公開モジュールを明示すること
25+
- Command レイヤーにビジネスロジックを書かないこと
26+
27+
## 命名規則
28+
29+
| 対象 | 規則 | 例 |
30+
|------|------|-----|
31+
| ファイル名 | `snake_case` | `port_scan.rs`, `arp_spoof.rs` |
32+
| 関数名・変数名 | `snake_case` | `get_active_network_info`, `lookup_vendor` |
33+
| 型名（struct / enum） | `PascalCase` | `AppError`, `NetworkInfo`, `PortScanResult` |
34+
| 定数 | `SCREAMING_SNAKE_CASE` | `MAC_ADDR_LEN`, `DEFAULT_PREFIX_LEN` |
35+
| コマンド関数名 | フロントエンドの `invoke` 名と一致 | `port_scan` → `invoke("port_scan")` |
36+
37+
## 非同期パターン
38+
39+
- 非同期ランタイムは **Tokio** を使用すること
40+
- 共有状態は `Arc<Mutex<T>>` で管理すること（参考: `arp_spoof_running` フラグ）
41+
- 長時間実行タスクは `tokio::spawn` で別タスクに分離し、状態フラグで制御すること
42+
- 並行数制限には `tokio::sync::Semaphore` を使用すること（参考: `port_scan` の実装）
43+
- セマフォの並行数は `config/default.toml` の設定値を使用し、ハードコードしないこと
44+
45+
## ログ出力
46+
47+
- `log` クレートのマクロ（`info!`, `warn!`, `error!`）を使用すること
48+
- エラー発生時は `log::error!` で記録した上で `AppError` を返すこと
49+
- `println!` / `eprintln!` は本番コードで使用禁止
50+
- ログメッセージには処理のコンテキスト情報（IP、ポート番号、インターフェース名等）を含めること
51+
52+
## feature フラグ
53+
54+
- Npcap / pcap 依存機能は `#[cfg(feature = "npcap")]` で囲むこと
55+
- `npcap` フィーチャー無効時はスタブ実装（エラーを返す）を用意すること
56+
- デフォルトビルド（`default = []`）は `npcap` フィーチャーなしで成功すること

‎.claude/rules/SECURITY.md‎

Lines changed: 45 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,45 @@
1+
# セキュリティ規約
2+
3+
本プロジェクトはペネトレーションテスト・CTF 学習用ツールであり、以下の規約を厳守すること。
4+
5+
## 倫理的使用の保証
6+
7+
- すべてのネットワーク攻撃機能（ARP スプーフ、スキャン等）は、実行前にユーザーの明示的な操作（ボタンクリック等）を要求すること
8+
- 自動実行・バックグラウンド自動起動を行う機能を実装しないこと
9+
- ARP スプーフ終了時は必ず ARP テーブルのリストア処理を実行すること（`reset_packet_count` 回のリストアパケット送信）
10+
- ツールの目的（学習・研究・正規テスト）を UI 上で明示すること
11+
12+
## 入力バリデーション
13+
14+
| 入力 | バリデーション |
15+
|------|-------------|
16+
| IP アドレス | `Ipv4Addr::parse()` で検証。不正な場合は `AppError::Scan` を返す |
17+
| ポート番号 | 0〜65535 の範囲内であることを確認 |
18+
| MAC アドレス | 6バイト形式であることを確認 |
19+
| ファイルパス | Tauri の `dialog` / `fs` プラグイン経由で取得。任意パスの直接入力を避ける |
20+
| ポートスキャン範囲 | `start <= end` であることを確認 |
21+
22+
- 外部入力は必ずパース・検証してからネットワーク処理に渡すこと
23+
- バリデーションは Command レイヤーで行い、実装レイヤーには検証済みの値を渡すこと
24+
25+
## 機密情報の保護
26+
27+
- キャプチャしたパケットデータ（pcap ファイル）のパスをログに出力しないこと
28+
- ネットワークスキャン結果（IP、MAC、ホスト名）をリモートに送信する機能を実装しないこと
29+
- すべてのデータはローカルに保持すること
30+
- 外部 API への通信は MAC ベンダー API（`macvendors.co`）のみ許可
31+
- API キーや認証情報をソースコードに含めないこと
32+
33+
## 依存クレートの管理
34+
35+
- ネットワーク関連クレート（`pnet`, `pcap`, `reqwest`）のバージョンアップ時はセキュリティアドバイザリを確認すること
36+
- 新規クレート追加時は `cargo audit` で脆弱性チェックを行うこと
37+
- `pcap` クレートは optional 依存とし、`npcap` feature フラグで制御すること
38+
- `npm audit` でフロントエンド依存の脆弱性も定期的に確認すること
39+
40+
## Tauri 権限
41+
42+
- capabilities には必要最小限の権限のみ定義すること
43+
- `shell:execute` など危険な権限は原則付与しないこと
44+
- 新機能追加時に権限が必要な場合は、その理由をコミットメッセージ / PR で明記すること
45+
- CSP（Content Security Policy）を本番ビルドでは適切に設定すること（現在は `null` で開発中）

‎.claude/rules/TAURI_COMMAND_DESIGN.md‎

Lines changed: 45 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,45 @@
1+
# Tauri コマンド設計規約
2+
3+
Tauri v2 のコマンド定義・状態管理・イベント通信に関する規約。
4+
5+
## コマンド定義パターン
6+
7+
- `#[tauri::command]` 関数は `commands/` ディレクトリに機能単位のファイルで配置すること
8+
- コマンド関数は薄いアダプター層とし、実装ロジックは `network/` や `utils/` に委譲すること
9+
- 新規コマンド追加時は `lib.rs` の `invoke_handler` に登録を忘れないこと
10+
- コマンドの戻り値型は `Result<T, AppError>` で統一すること
11+
- レスポンス構造体には `#[derive(Debug, Serialize, Clone)]` を付与すること
12+
13+
## 状態管理（AppState）
14+
15+
- アプリケーション全体の共有状態は `AppState` 構造体に集約すること
16+
- 現在のフィールド構成:
17+
18+
| フィールド | 型 | 用途 |
19+
|-----------|-----|------|
20+
| `config` | `AppConfig` | TOML 設定値 |
21+
| `http_client` | `reqwest::Client` | HTTP クライアント（再利用） |
22+
| `arp_spoof_running` | `Arc<Mutex<bool>>` | 長時間実行タスクの制御フラグ |
23+
24+
- 新しい共有状態が必要な場合は `AppState` にフィールドを追加すること
25+
- コマンド関数では `state: tauri::State<'_, AppState>` で注入すること
26+
27+
## イベント通信
28+
29+
- バックエンド → フロントエンドのリアルタイム通知には `window.emit("event-name", payload)` を使用すること
30+
- イベント名はケバブケース（例: `port-found`, `scan-progress`）で統一すること
31+
- ペイロードは `serde_json::json!({...})` で構築すること
32+
- 進捗通知は `config/default.toml` の `progress_report_interval` に基づいた間隔で発行し、フラッディングを防止すること
33+
34+
## Capabilities（権限制御）
35+
36+
- `src-tauri/capabilities/default.json` で必要最小限の権限のみ許可すること
37+
- 新しい Tauri プラグインを追加した場合は capabilities の更新を忘れないこと
38+
- 不要な権限は付与しないこと（最小権限の原則）
39+
40+
## 設定管理
41+
42+
- アプリケーション設定は `config/default.toml` で一元管理すること
43+
- `AppConfig` は `config.rs` で定義し、TOML ファイルからロードすること
44+
- デフォルト値はコード内の `Default` トレイト実装で提供すること
45+
- 設定値のロード順: 実行ファイルディレクトリ → 作業ディレクトリ → コード内デフォルト

‎.claude/rules/TESTING.md‎

Lines changed: 98 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,98 @@
1+
# テスト規約
2+
3+
## テストファイルの配置
4+
5+
- すべてのテストは `tests/` ディレクトリに配置すること
6+
- フロントエンドテスト: `{Component}.test.tsx` または `{module}.test.ts`
7+
- Rust 単体テスト: 各モジュール内に `#[cfg(test)] mod tests` で記述
8+
- Python テスト（ビルドスクリプト検証）: `test_*.py`
9+
10+
## フレームワーク
11+
12+
| レイヤー | フレームワーク | 環境 |
13+
|---------|-------------|------|
14+
| フロントエンド | Vitest + @testing-library/react | happy-dom |
15+
| Rust | 標準テスト (`#[test]`) | — |
16+
| ビルドスクリプト | pytest | Python (uv) |
17+
18+
## テスト実行コマンド
19+
20+
```bash
21+
# フロントエンドテスト
22+
npx vitest run
23+
24+
# カバレッジ付き
25+
npx vitest run --coverage
26+
27+
# Rust テスト
28+
cargo test --manifest-path src-tauri/Cargo.toml
29+
30+
# Python テスト
31+
uv run pytest tests/
32+
```
33+
34+
## テスト記述スタイル
35+
36+
### テスト観点表（必須）
37+
38+
テストファイルの冒頭に等価分割・境界値のテスト観点表をコメントとして記述すること:
39+
40+
```typescript
41+
/**
42+
* テスト観点表
43+
* | # | 観点 | 入力 | 期待結果 | 分類 |
44+
* |---|------|------|---------|------|
45+
* | 1 | 正常系 | 有効なIP | スキャン成功 | 等価 |
46+
* | 2 | 異常系 | 不正なIP | エラー表示 | 等価 |
47+
* | 3 | 境界値 | ポート0 | 正常動作 | 境界 |
48+
*/
49+
```
50+
51+
### Given / When / Then
52+
53+
各テストは Given / When / Then のコメントで構造化すること:
54+
55+
```typescript
56+
it("visible=falseの場合、何もレンダリングされないこと", () => {
57+
// Given: visible=false で NpcapDialog をレンダリング
58+
const { container } = render(<NpcapDialog visible={false} />);
59+
60+
// When: コンテナの中身を確認
61+
// Then: 何も表示されないこと
62+
expect(container.innerHTML).toBe("");
63+
});
64+
```
65+
66+
### テスト名
67+
68+
- 日本語で「〜こと」の形式で記述すること
69+
- 例: `有効なIPアドレスでスキャンが成功すること`
70+
71+
## テスト対象の優先順位
72+
73+
1. **共通コンポーネント** (`components/common/`) — 再利用されるため影響範囲が大きい
74+
2. **カスタム Hook** — ビジネスロジックの中核
75+
3. **デフォルト値・設定値** — 正しい値であることの保証
76+
4. **ページコンポーネント** — 結合テスト的な位置づけ
77+
78+
## カバレッジ目標
79+
80+
- 分岐網羅 100% を目指すこと
81+
- 失敗系テストは正常系と同数以上含めること
82+
83+
## テスト網羅要件
84+
85+
以下を必ず網羅すること:
86+
87+
- 正常系（主要シナリオ）
88+
- 異常系（バリデーションエラー、例外）
89+
- 境界値（0, 最小, 最大, ±1, 空, NULL）
90+
- 不正な型・形式の入力
91+
- 外部依存の失敗（該当する場合）
92+
- 例外種別・エラーメッセージの検証
93+
94+
## モック
95+
96+
- Tauri の `invoke` はモックして使用すること（実際のバックエンドに依存しない）
97+
- `vi.fn()` / `vi.mock()` を使用すること
98+
- `afterEach` で `cleanup()` と `vi.clearAllMocks()` を呼ぶこと

‎.claude/rules/TYPESCRIPT_REACT_CONVENTIONS.md‎

Lines changed: 51 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,51 @@
1+
# TypeScript / React コーディング規約
2+
3+
本プロジェクトのフロントエンドコード（`src/`）に適用する規約。
4+
5+
## ディレクトリ構造
6+
7+
| ディレクトリ | 役割 | 命名規則 |
8+
|------------|------|---------|
9+
| `pages/` | ページコンポーネント（ルーティング単位） | `{Feature}Page.tsx` |
10+
| `components/common/` | 再利用可能な共通コンポーネント | `{Name}.tsx` |
11+
| `components/{Feature}/` | 機能固有のコンポーネント群 | `{Name}.tsx` |
12+
| `hooks/` | カスタム Hook | `use{Name}.ts` |
13+
| `types/` | TypeScript 型定義 | `index.ts` に集約 |
14+
| `config/` | デフォルト値・定数 | `defaults.ts` |
15+
| `styles/` | 共通スタイルオブジェクト | `{name}Styles.ts` |
16+
17+
## Tauri コマンド呼び出し
18+
19+
- Tauri コマンドの呼び出しには `useTauriCommand<T>` 汎用 Hook を使用すること
20+
- 機能固有の複合操作は専用 Hook（例: `useArpSpoof`）でラップすること
21+
- ページコンポーネントから直接 `invoke` を呼ばないこと
22+
- コマンド名はスネークケースで記述し、Rust 側の関数名と完全一致させること
23+
- コマンド引数のキー名は Rust 側のパラメータ名（スネークケース）に合わせること
24+
25+
## 型定義
26+
27+
- Rust 側の Serialize 構造体と対応する TypeScript 型を `types/index.ts` に定義すること
28+
- `any` 型は使用禁止。`unknown` + 型ガードまたは適切な型パラメータを使用すること
29+
- Rust のフィールド名（`snake_case`）をそのまま TypeScript の型で使用すること（`camelCase` に変換しない）
30+
- ジェネリック型を活用して再利用性を確保すること（参考: `DataTable<T>`, `useTauriCommand<T>`）
31+
32+
## コンポーネント設計
33+
34+
- 関数コンポーネント + `React.FC` 型アノテーションを使用すること
35+
- Named export を使用すること（`default export` は `App.tsx` のみ例外）
36+
- Props 型は `interface {Component}Props` で定義すること
37+
- 状態管理は `useState` / カスタム Hook で行い、外部状態管理ライブラリは使用しないこと
38+
- ローディング状態とエラー状態は `LoadingSpinner` / `ErrorMessage` コンポーネントで表示すること
39+
40+
## スタイリング
41+
42+
- テーマ値（色、角丸、余白）は CSS 変数（`var(--accent)`, `var(--bg-secondary)` 等）を使用すること
43+
- 共通スタイルは `styles/formStyles.ts` に `React.CSSProperties` オブジェクトとして定義すること
44+
- インラインスタイルでハードコードされた色を使用しないこと
45+
- グローバルスタイルは `styles/global.css` で管理すること
46+
47+
## デフォルト値
48+
49+
- フォーム初期値などのデフォルト値は `config/defaults.ts` に定数として集約すること
50+
- ページコンポーネント内にマジックナンバーやデフォルト文字列を直書きしないこと
51+
- デフォルト値の定数名は `{FEATURE}_DEFAULTS` の形式とすること（例: `PORT_SCAN_DEFAULTS`）

0 commit comments

Comments
 (0)