build-project

技能：构建项目

将目标项目转换为 opentaint 项目模型：运行项目的构建，并在需要时解析其依赖项。构建工具、工具链和范围标志因语言而异——根据项目的构建文件识别目标语言，然后阅读对应的 references/<language>.md，并按照其中编号步骤操作；这些步骤与下文的步骤相对应。

输入

由调用方提供，省略时使用默认值。仅当必需输入缺失且没有合理默认值时才追问。

• project-root（可选）——目标项目的根目录。Opentaint 会将所有分析产物保存在固定的 <project-root>/.opentaint/ 目录下，因此下文的每个 .opentaint/... 路径都相对于该目录解析。默认值：当前目录
• build-hints（可选）——已知的项目构建信息：所需的工具链版本、要启用的模块或配置文件、项目特定的构建方式等

工作流

1. 重置输出

先删除任何现有的 .opentaint/project，以免旧模型中的文件混入新模型。

2. 确定构建方式

确定项目的构建方式——使用的构建工具，或是否提供了预编译产物。

3. 启用所有模块

重新启用项目禁用的所有模块，使其代码进入模型，然后在包含这些模块的情况下构建。启用已禁用模块属于配置编辑，而非源代码更改，因此模型仍代表当前提交。若经过合理尝试后仍无法使某个特定模块编译通过，则仅排除该模块。报告启用了哪些模块，以及排除了哪些模块（如果有）。

4. 自动构建器——首选方案

opentaint compile <project-root> -o .opentaint/project

opentaint compile 会运行项目的实际构建，因此能自动解析完整的依赖关系图和实际模块反应堆——无需手动列出依赖项或指定范围。先设置项目所需的构建工具链。几乎总是使用此方案。

反馈循环：此处的失败几乎总是可修复的构建问题，而不是放弃此方案的理由——自动构建器的包装器提示较为简略，因此不要仅凭提示判断问题是否可修复。直接重现项目自身的构建以显示实际错误，修复后重新运行 opentaint compile。

5. 手动构建 + opentaint project——最后手段

仅当完全无法让项目自身的构建通过时，才手动构建产物，然后使用 opentaint project 从这些产物创建模型，并将分析范围限制为项目代码。必须向分析器指出哪些代码属于项目、哪些属于第三方包。范围根目录应根据代码实际声明的内容确定，而不是根据构建配置或文件夹布局。仔细核对最终方法列表，这一点非常重要：必须列出所有第三方包。

6. 验证

确认 .opentaint/project/project.yaml 存在且非空，并且其中的模块和范围条目涵盖项目自身代码声明的每个根目录。对于多模块项目，确认包含预期数量的模块。确保 .opentaint/project/dependencies 下的依赖项已正确解析并下载。

7. 升级处理

如果经过约 3 次修复后构建仍未收敛 → 报告未收敛，并将构建阶段留待处理，由编排器介入。

输出

简短精炼地报告已完成的工作。

产物：

• .opentaint/project/ — opentaint 项目模型

摘要：

• 模型路径，以及（对于多模块项目）模型涵盖的模块数量
• 所选参考文档中定义的语言特定构建字段，以及成功构建时使用的值
• 模型的构建方式（自动构建器或手动构建），以及为使构建成功而修改的任何构建配置（例如重新启用的模块）
• 如果使用了 opentaint project，提供准确的构建命令和参数
• 如果构建未收敛：说明构建仍待处理，并列出阻塞错误和已尝试的修复

限制

• 仅将项目模型写入 .opentaint/project，不要生成任何其他文件。此技能不会写入任何跟踪状态，只会按“输出”返回信息
• 模型由 opentaint 生成，切勿手动编辑 project.yaml 或模型目录中的任何内容。若要更改分析内容，请修正命令并重新构建