review-sui-contracts

Sui コントラクトのレビュー

開発者の Sui Move コードを OpenZeppelin Contracts for Sui と照らし合わせて、AI がレビューします。ライブラリのオンチェーンプリミティブを正しく使用しているか、またライブラリの examples/、ドキュメントコメント、文書化された規約から逸脱していないかを確認します。

これは AI によるコードレビューであり、正式なセキュリティ監査ではありません。 誤用や逸脱を早期に指摘することで監査プロセスを支援しますが、独立した監査に代わるものではなく、レビューで問題が見つからなかったとしても安全性を保証するものではありません。

統合機能を構築するには develop-secure-contracts を、プロジェクトのひな形を作成するには setup-sui-contracts を使用してください。このスキルでは、すでに存在するコードをレビューします。

レビューの前に参照元を確認する

正しいパターンを把握していなければ、「誤った使用」や「逸脱」を指摘することはできません。そのため、記憶に頼らず、develop-secure-contracts スキルで定義された探索手順を使って、ライブラリ自体のメタデータからパターンを確認してください。インテグレーターがビルド対象とするリビジョンのプリミティブのAPI と動作を確認します。Move.lock から各 OZ 依存関係の固定リビジョンを特定し、main ではなく、そのリビジョンのソースとドキュメントコメントを参照してください。一方、ライブラリ全体のドキュメントである llms.txt、カタログ、ARCHITECTURE.md、STYLEGUIDE.md は、リポジトリの現在の main から確認してください。これらは継続的に更新されており、古い固定リビジョンには存在しないことも多いためです。コードで使用されている各 OZ プリミティブについて、以下から正式なパターンを確認してください。

• パッケージに examples/ があればその内容を、なければモジュールヘッダーのドキュメントコメントにある慣用的な使用例ブロックを確認します。これが標準的な使用例です（一部のパッケージには後者しかありません）。
• モジュールのドキュメントコメントと、生成された API リファレンス（カタログの Docs リンクからアクセスできます）。
• ARCHITECTURE.md（ケイパビリティモデル、オブジェクトの所有権、初期化）と STYLEGUIDE.md（規約）。

前提に頼らず、これらを基準にコードをレビューしてください。

レビュー項目

• OZ プリミティブの正しい使用。 コードは、コンポーネントが定義するケイパビリティ／ウィットネスを適切に引き回しているか（sender のチェックを独自に実装したり、ライブラリがすでに提供している機能を再実装したりしていないか）、正しい引数で関数を呼び出し、文書化されたアボート条件を処理しているかを確認します。
• 型引数を選ぶのは誰か、そしてそれは正しい型か。 ウィットネス型またはジェネリック型／phantom 型でパラメーター化された各 OZ プリミティブについて、誰がそれを渡すのか、またそれが適切な権限を持つ主体かを確認します。呼び出し側が選ぶ型は呼び出し側が制御する権限なので、信頼された側が固定しなければならず、呼び出し側に選ばせてはいけません。また、開発者が固定する型は、そのアクションに対して適切な型でなければなりません。下位権限ロールの Auth（または必要な保証より弱いウィットネス）で制限された特権操作は、権限昇格のバグです。
• リファレンスパターンからの逸脱。 フローを最も近い examples/ のレシピ（またはドキュメントコメントの慣用的な使用例）と比較し、それが維持する保証を弱める相違点を指摘します。たとえば、想定された所有権モデルに反してオブジェクトを埋め込むのではなく共有する、必須のセットアップ手順を省略する、返された値やレシートを無視する、またはドキュメントコメントに記載された不変条件を迂回する、といったケースです。
• コピーされたライブラリソース。 MVR 経由でインポートせず、OZ モジュールのソースをプロジェクトにコピーしている場合は指摘します。コピーはセキュリティ更新を取り込めません。
• 不変条件の維持。 OZ コンポーネントがドキュメントコメントや ARCHITECTURE.md で説明している不変条件がコードで維持されているかを確認します。たとえば、共有状態を保つ必要があるオブジェクト、上限内に保つ必要がある値、公開してはならないケイパビリティなどです。それらを破る可能性のある経路を指摘します。
• 統合テストのカバレッジ。 テストが正常系だけでなく、OZ の使用によって導入されるアボート経路や分岐経路（ロールによる拒否、期限切れ、上限超過、型違いなど）も対象にしているかを確認します。未テストの失敗経路には統合バグが潜んでいます。
• 既知の問題クラス（ヒューリスティック）。 OZ-on-Sui／Move コードで繰り返し見られる問題クラス（ケイパビリティの処理、丸め、オブジェクトの所有権、初期化など）についてコードを確認し、該当箇所があれば疑わしい点として挙げます。（ライブラリが公開している audits/ の監査資料は、これらの問題クラスを把握するための参考資料です。報告書自体は PDF であり、指摘事項のフィードではありません。）これは疑わしい点を見つけるためのセルフチェックであり、監査内容の再現やセキュリティ監査ではありません。

コード品質 — 規約を徹底する

OpenZeppelin の Sui 規約をレビューの主要な観点として扱い、違反は任意の提案ではなく指摘事項として報告します。ルールとレビュー手順が唯一の基準です。内容を繰り返すのではなく、適用してください。

• STYLEGUIDE.md — 規則をまとめたガイドです（命名、セクションの順序、インポート、慣用的な Move 2024、テスト、ドキュメント、リンターの抑制）。
• .claude/commands/code-quality.md — .move ファイルを STYLEGUIDE.md と照合する標準手順です。レビュー対象のコードに対して実行してください。
• リンターは任意ではありません。 プロジェクトの --build-env と --lint を使用してビルドとテストを実行してください（正確な呼び出し方法は setup-sui-contracts を参照）。スタイルガイドに従い、警告は #[allow(...)] で抑制せず、必ず修正してください。--lint はコンパイラーでチェック可能な範囲を個別に適用するため、STYLEGUIDE.md を一時的に取得できない場合は、規約の確認を省略せず再試行してください。

各違反について、該当する STYLEGUIDE.md のセクションを示してください。

報告する前に検証する

上記のチェックは問題を見つけることを重視しています。したがって、何かを書く前に、それぞれの指摘が誤りである可能性を検討してください。該当する行を正確に引用し、問題が本当に存在することを確認してください。それが意図された、文書化済みの選択ではなく、実際の逸脱であることを確認してください。そして、具体的な一行の修正案を提示できることを確認してください。この3つすべてを満たさない指摘は除外し、重要度の基準は高く保ってください。開発者が信頼して読める短いレビューは、流し読みされる長いレビューに勝ります。

出力

重要度の高い順に指摘を並べ、レビューを1つ作成してください。各指摘は、file:line — 問題点（1節）→ 修正案（1節） — 逸脱している OZ の example またはドキュメントコメント、という形式にして、開発者が直接比較できるようにします。短い前置きは有用です。対象範囲や境界、ビルド／テスト／lint のステータスを記載してください。問題なく統合されている場合は、「検証済み、問題なし」の1行で構いません。本文には指摘のみを記載し、要約は含めません。

プロジェクトをビルドできる場合は、レビュー内容がコンパイル済みコードを反映するよう、先にチェックを実行してください（setup-sui-contracts に従って sui move build／test を実行）。ビルド／テストの失敗は、パターンに関する指摘とは分けて報告してください。

範囲

• インテグレーターのコード、つまりライブラリの使い方をレビューします。OpenZeppelin ライブラリ内部そのものは対象外です。
• セキュリティ監査ではありません。網羅的な脅威モデリングや完全性の保証は行いません。本番コードについては、正式な監査を推奨してください。
• develop-secure-contracts（統合）および setup-sui-contracts（スキャフォールディング）を補完するものであり、ビルドやスキャフォールディングは行いません。