1k-code-review-pr

OneKey PR コードレビュー

出力言語: 中国語

レビュー範囲

• ベースブランチ: x
• 差分: git fetch origin && git diff origin/x...HEAD（三点ドット）

ワークフロー

1. チェックアウト — gh pr checkout <PR_NUMBER>（すでにブランチにいる場合はスキップ）
2. 範囲の確認 — git diff origin/x...HEAD --stat で変更範囲を確認
3. トリアージ — 適用するレビュー モジュールを判断（トリアージ表を参照）
4. 一次レビュー — 変更された各ファイルを読み、references/ から関連するチェック項目を適用
5. Codex クロスレビュー — Codex を利用できる場合は、並行して完全なレビューを実行（以下を参照）
6. PR コメント分析 — 既存の PR コメントをすべて取得（ボットと人間の両方）し、ローカルのコードベースのコンテキストを使って分析（以下を参照）
7. 指摘事項の統合 — 一次レビュー、Codex、PR コメントの指摘事項を統合し、重複を排除して信頼度を付与
8. スコアリング — 4 つの観点で PR を評価（スコアリングシステムを参照）。このステップは必須です。すべてのレポートにスコアリング表を含めてください。
9. レポート — 統一形式を使用して構造化レポートを作成。テンプレートに正確に従ってください。すべてのセクションが必須です。
10. GH コメント — 条件を満たす指摘事項をインライン PR コメントとして直ちに投稿（確認を待たない）

Codex クロスレビューの統合

codex:codex-rescue サブエージェントタイプをディスパッチできることを確認し、Codex が利用可能かどうかを確認してください。不確かな場合は、/codex:setup を呼び出して準備状況を確認してください。

利用可能な場合:

1. Agent(subagent_type="codex:codex-rescue") を使って、完全かつ独立したレビューを Codex にディスパッチします:

   Agent(
     subagent_type = "codex:codex-rescue",
     prompt = "Review this PR diff for the OneKey crypto wallet monorepo. Focus on:
   - Security vulnerabilities (secret leakage, auth bypass, supply-chain risks)
   - Runtime bugs (race conditions, null safety, memory leaks)
   - Architecture violations (import hierarchy, cross-platform issues)
   - Code quality (hooks safety, error handling, performance)
   Report each finding with: file:line, severity (Critical/High/Medium/Low), description, fix suggestion.
   
   Diff:
   ${FULL_DIFF}"
   )
   

2. Agent の結果を解析して構造化された指摘事項を抽出します
3. 一次レビューに統合します:
   • 同じ問題を両方が発見 → {Cross-validated ✅} とマークし、信頼度を自動的に 🔵 High に引き上げます
   • Codex のみが発見 → [Codex] タグを付けて含め、手動で信頼度を割り当てます
   • 一次レビューのみが発見 → 通常どおり含めます
4. レポートに Codex 交差検証摘要 の表を追加します（レポートテンプレートを参照）

利用できない場合: 何も言わずにスキップします。レポートヘッダーに「Codex 交差検証: ⏭️ 未启用」と設定します。それ以外の箇所では Codex に言及しないでください。

PR コメント分析

PR 上の既存コメントをボットと人間の両方からすべて収集し、ローカルのコードベースのコンテキストを使ってそれぞれ分析します。ソースコード、型システム、依存関係グラフをすべて利用できます。ほとんどのコメント投稿者が確認したのは差分だけです。この情報の非対称性を活用してください。

すべてのコメントの取得

ユーザーメタデータ（ボット判定用の type フィールドを含む）をすべて取得するには、gh api を使用します:

# Top-level PR reviews (review bodies)
gh api repos/{owner}/{repo}/pulls/{pr_number}/reviews \
  --jq '[.[] | select(.body != "") | {author: .user.login, is_bot: (.user.type == "Bot"), body: .body, state: .state, association: .author_association}]'

# Inline review comments (file:line annotations)
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments \
  --jq '[.[] | {author: .user.login, is_bot: (.user.type == "Bot"), path: .path, line: .line, body: .body, association: .author_association}]'

# General PR comments (issue-level)
gh api repos/{owner}/{repo}/issues/{pr_number}/comments \
  --jq '[.[] | {author: .user.login, is_bot: (.user.type == "Bot"), body: .body, association: .author_association}]'

ボットの判定 — ハードコードされたユーザー名のリストではなく、GitHub API の user.type == "Bot" フィールドを使用します。これにより、メンテナンス不要で現在および将来のあらゆるボットを自動的に対象にできます。

コメントがない場合は、レポートヘッダーに「PR コメント分析: ⏭️ 無评论」と設定し、このセクションをスキップします。

分析フレームワーク

実質的なコメントごとに（空の承認コメント、CI ステータスバッジ、書式だけのコメントはスキップ）:

判定	意味	対応
✅ 確認済み	コメントが実際の問題を特定している	指摘事項に含め、ソースを [<author>] としてタグ付け
🔍 詳細化	実際の問題だが、分析が浅い、または修正方法が誤っている	コードベースの知識に基づく、より詳細な修正案とともに含める
❌ ノイズ	コードベース全体のコンテキストを踏まえると問題ではない	「评论误报分析」に、問題ではない理由を簡潔に記載
📋 対応済み	一次レビューですでに検出済み	相互検証し、信頼度を引き上げる

ローカル環境での優位性 — 積極的に活用してください:

• ソース全体 — 差分だけでなく、ファイル間のデータフローを追跡します
• 型システム — tsc を実行し、エンドツーエンドで型を検証します
• アーキテクチャ — OneKey のインポート階層とプラットフォームのパターンを把握しています
• 依存関係 — yarn info、変更履歴、実際の脆弱性への到達可能性を確認します
• ランタイムの推論 — 状態の流れ、非同期ライフサイクル、競合状態を検証します

曖昧な指摘を受けたら、ソースを掘り下げて確認または反証してください。コメントがコンテキストを見落としている場合（たとえば、上流で関数が安全にガードされている場合）は、その理由を説明してください。コメントが正しい場合は、より豊富なコンテキストを加えて補強してください。

クロスバリデーションルール

• コメントと一次レビューが一致 → {Cross-validated ✅} とマークし、🔵 High に引き上げます
• コメントのみの指摘を確認できた場合 → 適切な信頼度で含め、[<author>] タグを付けます
• コメントのみの指摘について、確認も反証もできない場合 → ⚪ Low として、注記を添えて含めます
• 証拠をもとに反証したコメント → 「コメントの誤検出分析」セクションに追加します

セキュリティコメントの特別な取り扱い

セキュリティ関連のコメント（Snyk／Dependabot などのボット、または人間のレビュアーによるもの）について：

• 脆弱性レポート — OneKey での使用時に、脆弱なコードパスに実際に到達可能か確認します
• ライセンスの問題 — OneKey のライセンスポリシーと照らして確認します
• 依存関係のアラート — 指摘されたバージョンが実際に使用されているか確認します（ロックファイルに記載されているだけではないこと）

トリアージ：実行するチェック

git diff origin/x...HEAD --name-only を実行し、該当する項目を確認します。

変更されたファイルのパターン	読み込むもの
package.json、ロックファイル、node_modules のパッチ、patches/*.patch	[security-and-supply-chain.md] — サプライチェーン全体のレビュー
**/auth/**、**/vault/**、**/signing/**、**/crypto/**、manifest.json、**/manifest/*.js	[security-and-supply-chain.md] — セキュリティ全体のレビュー
ビジネスロジックを含む .ts／.tsx ファイル	[code-quality-patterns.md] — フック、競合状態、null 安全性
.android.ts(x)、.ios.ts(x)、.native.ts(x)、.desktop.ts(x)、.ext.ts(x)、.web.ts(x)、ネイティブモジュール、BigNumber の使用	[onekey-platform-patterns.md] — プラットフォームのクラッシュと数値の安全性
シェルスクリプト（.sh）、CI ワークフロー（.yml）	[onekey-platform-patterns.md] — ビルドと CI のセクション

ファイルの種類に関係なく、必ず確認します：

• 意図しないファイルのコミット（.DS_Store、.env、node_modules）
• インポート階層の違反（以下を参照）
• 安定した既存のヘルパー、フック、サービス、コンポーネントで同じ動作をカバーできるのに、回避可能な再実装が行われていないか（以下を参照）
• PR の説明が実際の変更内容と一致しているか
• [quick-commands.md] の関連コマンドを実行します

インポート階層（必ず確認）

@onekeyhq/shared     <- FORBIDDEN to import from other OneKey packages
    ↓
@onekeyhq/components <- ONLY imports shared
    ↓
@onekeyhq/core       <- ONLY imports shared
    ↓
@onekeyhq/kit-bg     <- imports shared, core (NEVER components or kit)
    ↓
@onekeyhq/kit        <- imports shared, components, kit-bg
    ↓
apps/*               <- imports all

# Quick hierarchy violation check on changed files
git diff origin/x...HEAD --name-only | grep -E '\.tsx?$' | \
  while IFS= read -r f; do [ -f "$f" ] && grep -l "from.*@onekeyhq" "$f" 2>/dev/null; done | \
  while IFS= read -r f; do echo "=== $f ==="; grep "from.*@onekeyhq" "$f"; done

既存実装の再利用（必ず確認）

新たに追加されたヘルパー、フック、サービス、コンポーネント、定数、フォーマッター、バリデーター、ビジネスロジックについて：

• 新しいコードを受け入れる前に、同じ目的の既存実装がコードベースにないか検索します。
• ローカルで再実装するより、確立された OneKey の API、コンポーネント、フック、ユーティリティ、サービスメソッドを優先します。
• 既存の抽象化が意味的に同等で、安定しており、結合を悪化させない場合に限り、再実装として指摘します。
• 再利用に関する指摘には、再利用する既存のファイル／関数を記載し、それが新しい動作をカバーできる理由を説明します。

ファイルのリスク分類

リスク	パターン	対応
Critical	**/vault/**、**/signing/**、**/crypto/**、**/core/src/**、ハードウェアウォレット SDK	行ごとにレビューします
High	**/auth/**、API エンドポイント、状態管理、package.json、manifest.json	詳細にレビューします
Medium	UI コンポーネント、プラットフォーム固有のコード、バックグラウンドサービス	標準的なレビューを行います
Low	コメント、型のみの変更、フォーマット、テスト、ドキュメント	異常がないか確認します

スコアリングシステム

必須 — 例外なく、すべてのレポートにこのスコアリング表を含めてください。

PR を4つの評価軸で採点してください（各1～10点）。

評価軸	重み	評価内容
🔒 安全性	35%	シークレットの漏えい、認証の迂回、サプライチェーンのリスク、入力の検証
💎 コード品質	30%	フックの安全性、エラー処理、競合状態、null の安全性、DRY、既存実装の再利用
🏛️ アーキテクチャの妥当性	20%	インポート階層、関心の分離、クロスプラットフォームでの一貫性
✅ 完全性	15%	エッジケースへの対応、テストカバレッジ、移行パス、ドキュメント

総合スコア = 加重平均を小数第1位に四捨五入した値。

スコア	判定	対応
8.0 - 10.0	✅ そのままマージ可能	ブロッカーはなく、軽微な提案のみ
5.0 - 7.9	⚠️ 修正後に再レビューが必要	マージ前に修正すべき問題があります
< 5.0	❌ 差し戻して作り直すことを推奨	セキュリティまたはアーキテクチャに根本的な問題があります

スコアの基準 — 採点の一貫性を保つために：

• 各評価軸を8点から始め、見つかった問題に応じて減点します
• P0 のセキュリティ問題が1つでもある場合 → 安全性の上限は3点です
• P0 のクラッシュ／実行時バグが1つでもある場合 → コード品質の上限は5点です
• インポート階層違反がある場合 → アーキテクチャの上限は4点です

信頼度レベル

必須 — すべての指摘には、次の3つの絵文字タグのうち、必ず1つだけを使用してください。パーセンテージを使わないでください。また、絵文字なしで「高／中／低」のようなテキストだけを使わないでください。必ずこの形式をそのまま使用してください。

タグ	意味	使用する場合
🔵 High	確認済み。コードから検証可能	明確なバグ、明らかな違反、再現可能
🟠 Medium	問題の可能性が高いが、背景情報が必要	パターンから問題が示唆されるが、意図的な可能性もある
⚪ Low	問題の可能性があり、確認が必要	ヒューリスティックによる一致。ビジネスロジックに依存する

相互検証された指摘（一次レビューと Codex が一致、または一次レビューと PR コメントが一致）→ 自動的に 🔵 High とします。

自動修正パッチ

次のカテゴリでは必須 — 指摘がいずれかに該当する場合、必ず diff パッチを含めてください。

• console.error/warn/log → プロジェクトのロガー（defaultLogger）
• null 許容の ref にオプショナルチェーンがない
• インポート階層違反
• useEffect にクリーンアップがない
• BigNumber の型強制（Number(decimals)）
• ユニオン型定義に型がない

形式 — 必ず次の構造をそのまま使用してください。

**Auto-fix:**
\```diff
- old code
+ new code
\```

修正が明確で、ビジネス上の背景を必要としないその他の指摘にも、自動修正を含めてください。迷った場合は含めてください。修正案がないより、提案があるほうが役立ちます。

自動修正を生成しないでください。

• ビジネス上の背景を理解したうえでのロジック変更
• アーキテクチャ上の判断が必要なセキュリティ修正
• トレードオフのあるパフォーマンス最適化

GH CLI のインラインコメント

レポートの生成後、コメントの基準を満たす指摘がある場合は、すぐに投稿してください。「確認しますか？」と尋ねたり、追加メッセージを待ったりしないでください。新しい会話には「今後はすべて自動で投稿して」という口頭での指示は引き継がれません。このセクションが正式な指示です。

コメントの基準：P0（信頼度は問わない）、または 🔵 High の P1。つまり、次のとおりです。

• すべての P0 の指摘（信頼度は問わない）
• 🔵 High の P1 の指摘すべて（相互検証済み、またはコードから確認済み）
• 対象外：P2 の指摘、および 🟠 Medium または ⚪ Low の P1 の指摘

1. PR コメントの対象となる、基準を満たした指摘を一覧表示します
2. 利用可能な場合は ManagePullRequest の post_comment（パス＋行）を使用し、それ以外の場合は次の方法で、レポートと同じターンに投稿します。

# Inline comment on specific file:line
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments \
  --field body="**[P1] 问题标题**: 描述...

**建议修复:**
\`\`\`suggestion
修复代码
\`\`\`

_— Auto-review by Claude_" \
  --field path="path/to/file.tsx" \
  --field line=42 \
  --field side="RIGHT" \
  --field commit_id="$(git rev-parse HEAD)"

ルール：

• 対象となる指摘は、レビュー報告と同じターンに必ず投稿してください
• 上記のコメント基準を満たす指摘だけを投稿してください
• 利用可能な場合は suggestion ブロックに自動修正を含めてください
• PR ごとのインラインコメントは最大5件です
• GitHub のレビューコメントは PR の差分にある行にのみ付けられます。実際の箇所に変更がない場合は、最も近い変更行にコメントし、本文で変更のない箇所を示してください
• 既存のインラインスレッドで同じ問題がすでに指摘されている場合は、重複したスレッドを作成せず、そのスレッドに返信してください

統一レポート形式

重要：このテンプレートに厳密に従ってください。[REQUIRED] と記されたセクションはすべて、各レポートに必ず含めてください。セクションを省略したり、順序を入れ替えたりしないでください。

# PR #NUMBER 代码审查报告

## 审查概要 [REQUIRED]
- **变更范围**: X 个文件, +Y / -Z 行
- **风险等级**: Critical / High / Medium / Low
- **涉及平台**: Extension / Mobile / Desktop / Web
- **Codex 交叉验证**: ✅ 已启用 / ⏭️ 未启用
- **PR 评论分析**: ✅ 已分析 (N 条评论, 其中 M 条来自 Bot) / ⏭️ 无评论

## 评分 [REQUIRED — NEVER SKIP THIS SECTION]

| 维度 | 得分 | 说明 |
|------|------|------|
| 🔒 安全性 | X/10 | 简要说明 |
| 💎 代码质量 | X/10 | 简要说明 |
| 🏛️ 架构合理性 | X/10 | 简要说明 |
| ✅ 完整性 | X/10 | 简要说明 |
| **总分** | **X.X/10** | **✅ 可直接合入 / ⚠️ 需修改后复审 / ❌ 建议打回** |

## Codex 交叉验证摘要 [REQUIRED if Codex was used, OMIT if not]

| 发现 | Primary | Codex | 状态 |
|------|---------|-------|------|
| 问题描述 | Yes/No | Yes/No | 交叉验证 / 仅 Primary / 仅 Codex |

## PR 评论分析 [REQUIRED if comments exist, OMIT if none]

| 来源 | 类型 | 发现 | 判定 | 说明 |
|------|------|------|------|------|
| Snyk | 🤖 Bot | 依赖漏洞 CVE-XXXX | ✅ Confirmed | 漏洞路径在 OneKey 中可达 |
| @reviewer | 👤 Human | 缺少 null check | 🔍 Enriched | 实际需要在上游 hook 中处理 |
| Devin | 🤖 Bot | 变量命名建议 | ❌ Noise | 命名符合项目规范 |

### 评论误报分析 [OMIT if no noise findings]
- **[来源] 误报**: 具体说明为什么这不是问题（引用源码上下文）

## 发现的问题 [REQUIRED]

### [P0] [🔵 High] 问题标题 {Cross-validated ✅}
**文件**: `path/to/file.tsx:42`
**类型**: 安全 / 构建 / 运行时 / 性能 / 规范
**描述**: 问题是什么，为什么有风险
**Auto-fix:**
\```diff
- old code
+ new code
\```

---

### [P1] [🟠 Medium] 问题标题
**文件**: `path/to/file.tsx:18`
**类型**: 运行时
**描述**: ...
**修复建议**: ...

---

## 修改清单 [REQUIRED]

| 优先级 | 置信度 | 文件 | 类型 | 描述 | Auto-fix |
|--------|--------|------|------|------|----------|
| P0 | 🔵 High | file1.tsx:42 | 安全 | 描述 | ✅ |
| P1 | 🟠 Medium | file2.tsx:18 | 运行时 | 描述 | — |

## 测试建议 [REQUIRED]
1. 测试场景
2. 测试场景

## GH 评论操作 [REQUIRED if qualifying findings exist, OMIT if none]
以下问题（P0 任意置信度，或 P1 + 🔵 High 置信度）建议直接评论到 PR：
- [ ] 问题1 — `file.tsx:42`
- [ ] 问题2 — `file.tsx:88`

> 达标问题已在本回合直接发为 inline comments，无需再确认。

優先度の定義

必須 — すべての指摘には、優先度として P0～P2 のタグを必ず1つ付けてください。指摘の優先度ラベルに、高／中／低や Critical／High／Medium／Low を使わないでください。

優先度	基準	対応
P0	セキュリティ脆弱性、鍵／資金の漏えい、データ損失、クラッシュ、ユーザーに影響する実行時バグ、ビルド失敗	ブロッカー — マージ前に必ず修正
P1	エッジケースのバグ、並行処理のリスク、堅牢性の不足、保守性の問題	マージ前に修正することが望ましい
P2	あると望ましいもの、軽微な不整合、細かな指摘（命名、コメント、スタイル）	フォローアップ／任意

過去の PR スレッドでは、従来の5段階評価が使われている場合があります。分析する際は、旧 P1 → P0、旧 P2 → P1、旧 P3／P4 → P2 に対応させてください。

レビューの方針

• コードを読む — grep するだけで済ませないでください。変更されたファイルをそれぞれ読み、意図を理解してください。
• 誤検出を避ける — 確信がある問題のみ報告してください。確信が持てない場合は、信頼度を下げてください。
• スタイルに関する細かな指摘はしない — セキュリティ、正確性、アーキテクチャ、パフォーマンスに注力してください。
• 背景が重要 — 変更を提案する前に、なぜそのコードがこのように書かれたのかを理解してください。
• まず再利用を検討する — 新しい抽象化や重複するビジネスロジックを受け入れる前に、既存のローカル実装を検索し、不要な再実装があれば、具体的な再利用先を示して指摘してください。
• 優先順位を付ける — 質の高い指摘3件は、際どい指摘20件に勝ります。
• 正直に評価する — スコアは外交的な配慮ではなく、実態を反映してください。
• 積極的に自動修正する — 修正方法が明確な場合は、必ず差分パッチを含めてください。レビュー担当者は、すぐに対応できる提案を好みます。

参照ファイル

• references/security-and-supply-chain.md — PII 漏えい、認証／認可、サプライチェーン、マニフェストの権限
• references/code-quality-patterns.md — フック、競合状態、null 安全性、同時リクエスト、エラー処理
• references/onekey-platform-patterns.md — Android／iOS のクラッシュ、Fabric、BigNumber、ビルド／CI
• references/quick-commands.md — 自動チェック用の Bash ワンライナー