review-sui-contracts

审查 Sui 合约

借助 AI，根据 OpenZeppelin Contracts for Sui 审查开发者的 Sui Move 代码：代码是否正确使用了库的链上原语？有哪些地方偏离了库的 examples/、文档注释和已记录的约定？

这是 AI 代码审查，不是正式安全审计。 它通过及早指出误用和偏差来支持审计流程；不能替代独立审计，审查结果良好也不代表安全有保障。

如需构建集成，请使用 develop-secure-contracts；如需搭建项目脚手架，请使用 setup-sui-contracts。此技能用于审查已经存在的代码。

在审查前确定参考依据

如果没有掌握正确模式，就无法指出“使用不当”或“偏离”之处——因此，请使用 develop-secure-contracts 技能定义的发现链，从库自身的元数据中查找，切勿凭记忆判断。阅读集成方所构建版本中的原语 API 和行为——从 Move.lock 中解析每项 OZ 依赖固定的 rev，并使用该版本的源代码和文档注释，而不是 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、测试、文档、lint 抑制）。
• .claude/commands/code-quality.md — 检查 .move 文件是否符合 STYLEGUIDE.md 的权威流程；请对审查中的代码运行该流程。
• Lint 并非可选。 使用项目的 --build-env 和 --lint 执行构建与测试（确切命令请参见 setup-sui-contracts）；根据样式指南，必须修复警告，绝不能用 #[allow(...)] 抑制。--lint 会独立强制执行可由编译器检查的部分，因此如果暂时无法获取 STYLEGUIDE.md，请重试，不要跳过规范检查。

针对每项违规，指出其违反的 STYLEGUIDE.md 章节。

报告前验证

上述检查旨在发现问题，因此在撰写任何内容之前，请先尝试证伪每项发现：引用确切行号并确认问题确实存在；确认这是真正的偏离，而非有意且有文档说明的选择；并确认你能给出具体的一行修复方案。未能通过这三项验证的内容一律舍弃，并保持较高的严重性门槛——开发者信任的简短审查，胜过他们会略读的长篇报告。

输出

生成一份审查报告，按严重性排序列出发现。每项发现的格式为：file:line — 问题所在（一句话）→ 修复方案（一句话）— 以及它偏离的 OZ example 或文档注释，供开发者直接对照。简短的前言会很有帮助——说明审查范围和边界，以及构建／测试／lint 状态；如果集成代码没有问题，一句“已验证并通过”即可；正文只列发现，不要重复总结。

如果项目可以构建，请先运行检查（根据 setup-sui-contracts 运行 sui move build / test），确保审查基于可编译的代码，并将构建／测试失败与模式问题分开报告。

边界

• 审查的是集成者的代码——即其使用库的方式，而非 OpenZeppelin 库内部代码本身。
• 这不是安全审计——不进行穷尽式威胁建模，也不保证审查完整性；生产代码建议进行正式审计。
• 这是对 develop-secure-contracts（集成）和 setup-sui-contracts（脚手架搭建）的补充；它既不负责构建，也不负责搭建脚手架。