这项任务先解决什么
归档源文件指纹、导出设置、资源路径、修改说明与验证记录。再分发前逐个查网格、纹理、脚本和品牌标志的权利。接收者在目标软件中复跑尺寸和关节，不只确认压缩包能解开。
交付原始和转换文件、资源路径及许可记录。网格原点或尺度变更后，关节与碰撞检查也可能需重做；接收人按目标环境执行，不只确认压缩包可打开。
交付对象先能找到，再能复跑
交接机器人模型导入项目时，先让模型开发与接收人员确认资料清单和文件位置，再依照文档执行一遍关键流程。作者在旁口头补充的步骤也要回写说明，不能只以文件已发送或压缩包能打开作为完成。当前版本、来源、修改及仍未确认的事项应一并交接，让接收人知道哪些材料可以使用、哪些还需补证。
三类材料分别确认
交付包第1类采用“机器人模型导入表”，用途是标记源文件与目标用途。。接收时逐项核对文件、来源/许可、用途、源单位、目标环境、未知项，把示例行与实际项目行分开。没有执行的检查保持待执行，不将示例中的假设写成已测结果；更换文件或条件后在修订栏说明影响范围。
交付包第2类采用“尺度关节碰撞复核”，用途是明确示例是练习，不是真实产品参数。。接收时逐项核对对象、假设/实测、已知基准、检查层、结果、修订，把示例行与实际项目行分开。没有执行的检查保持待执行，不将示例中的假设写成已测结果；更换文件或条件后在修订栏说明影响范围。
交付包第3类采用“模型交付与权利清单”，用途是每份依赖分别记录许可。。接收时逐项核对材料、版本/指纹、许可来源、修改、复跑证据，把示例行与实际项目行分开。没有执行的检查保持待执行，不将示例中的假设写成已测结果；更换文件或条件后在修订栏说明影响范围。
问题单与变更应能接着推进
交付后的记录重点是源文件、许可、单位、坐标变换、关节、碰撞体与复测版本。每个未关闭问题指定责任角色、下一项证据和复核动作，避免一句“后续沟通”让问题失去归属。若“含关节描述的模型”被替换为另一种路径，先对照父子、原点、轴、限位及依赖及原有取舍，再确认哪些旧记录仍有效，哪些需重新执行。
把技术边界放到实际动作里
本次核对还要保留两条具体提醒。第一，网格已摆到正确位置不等于关节原点与轴已经正确。；对应动作是逐个关节单独施加小幅命令。第二，无碰撞警告不能作为真实工位安全的结论。；可从用简单受控接触验证碰撞开始复核。它们应进入操作说明或问题单，而不是只出现在结尾。若结果与预期不同，先查这些动作是否真的完成，再决定是否需要修改原任务。
模型交付与权利清单：怎样填写本次任务
本场景工作表字段为材料、版本/指纹、许可来源、修改、复跑证据。例如示范行“网格 / 待填 / 待核对 / 待记录 / 尺寸核对”仅展示填写关系；实际运行后用自己的观察替换，不保留示例当结果。填写时重点对应源文件、许可、单位、坐标变换、关节、碰撞体与复测版本，让一次选择、操作或修改能找到原始依据。表头中的状态应区分未执行、已观察和仍待确认，适用条件改变时另开一行，而不是覆盖旧结果。
本场景最容易误判的两件事
围绕“模型交付打包：文件、转换与许可不能分家”，可以把这两个问题用于复核。网格能用于仿真吗？ 可作为几何输入，但关节、碰撞和物理参数需另核对。 另一项是：关节方向反了直接改符号吗？ 先核对坐标系、原点和轴定义，避免修错层。 两者应与本次任务的实际条件一起判断。
原始资料阅读
glTF Specification Registry
https://registry.khronos.org/glTF/
REP 103 — Standard Units of Measure and Coordinate Conventions
https://github.com/ros-infrastructure/rep/blob/master/rep-0103.rst
Recommended practices for attribution
https://wiki.creativecommons.org/wiki/Best_practices_for_attribution