BackboneNeo/ai-skills-cad-engineering

CAD 工程工作流

将仓库说明和仓库拥有的验证器视为权威。利用本技能使工作系统化；切勿用通用假设取代特定项目需求。

1. 建立契约

1. 在编写之前，阅读所有适用的 AGENTS.md、完整项目指南、当前图纸快照以及请求的 Issue。
2. 识别不可变基线标签、CAD 路径、SHA-256、坐标系、单位系统、当前组件清单、预期可打印实体以及发布目标。
3. 如果真相来源冲突或基线无法验证，则在编辑前停止。
4. 将请求的结果与相关 Issue 的上下文分开。不要将积压工作吸收到任务中。
5. 选择 Issue、仓库策略或用户声明的发布轨道：数字 CAD/图纸或物理合格产品。图纸发布并不代表产品合格。
6. 根据该权威契约，将每个验收标准分类为计算型、视觉型、物理型或仅操作员型。对于图纸轨道，诸如配合、安装、拆卸、夹紧、驱动、布线或访问等措辞意味着数字几何/路径验证，除非契约明确要求制造样品或动手测试。切勿将通用工程风险提升为强制性门槛，也切勿仅凭几何数据就报告物理标准已通过。

在选择或验证基线时，请阅读 baseline-and-source-truth.md。在修复现有失败候选者之前，请阅读 failure-patterns.md。

2. 修改前检查

1. 打开现有原生 CAD 文档并检查其树、对象类型、表达式、属性、放置、组、实体、可见性和重新计算状态。

2. 记录机器可读的基线报告。当 FreeCAD 可用时，运行：

   python scripts/run_inspect_fcstd.py --freecad FreeCADCmd.exe --file <baseline.FCStd> --output <baseline-report.json>

3. 不要从网格、STEP、屏幕截图、快照或引导生成器重建现有原生文档。

4. 不要覆盖用户保存的放置、颜色、可见性、表达式或手动编辑，除非任务明确要求进行这些确切更改。

5. 当仓库规则使历史版本不可变时，在新的版本化路径中工作。

3. 实施最小的完整工程变更

1. 使用精确、固定的组件源。将可编辑源、精确导入的工件、出处版本和 SHA-256 一起保存。
2. 将外部组件放置在仓库的嵌入源组中，并从验证过的模型中派生安装几何。
3. 在其原生上游特征处替换遗留几何。切勿通过将补丁、板、塞子、蒙皮、填充物或共面修复融合到下游成品实体中来隐藏过时的孔、凹坑、浮雕或安装特征。
4. 如果无法恢复原生特征前实体或可编辑构建链，则停止并标记为阻塞。不要仅仅为了获得请求的最终包络而用添加性修复几何来替代。
5. 当仓库要求基于草图的控制时，保持控制几何可编辑且完全约束。
6. 通过可检查的依赖关系或顺序布尔链，将每个控制特征连接到最终可打印实体。草图或切割器的存在并不证明集成已实现。
7. 更换组件时，移除过时的特定于组件的切割、浮雕、标签、活动嵌入源以及下游残留物。
8. 限制附带更改。保留不相关的组件放置、可打印实体、坐标系、外观和文档结构。

对于每次更换或调整尺寸的开口，请阅读并遵循 native-feature-replacement.md。对于组件工作，请阅读 component-integration.md；对于原生建模和布尔运算，请阅读 parametric-geometry.md。

4. 分层验证

在每个有意义的几何组之后运行验证，而不仅仅是在最后。

1. 重新计算并拒绝文档错误。
2. 保存、关闭、重新打开、重新计算、保存，然后再次重新打开。
3. 确认预期的可打印实体数量、实体数量、边界、体积和拓扑结构。
4. 证明请求的特征影响预期的最终实体。
5. 对于更换操作，证明受影响的局部实体等于仅应用了新预期操作的原生未修改特征。拒绝残留的遗留轮廓、添加性修复依赖项、额外的共面边界以及隐藏的填充体。
6. 分别检查碰撞和所需接触。所需的安装接触不是意外的碰撞。
7. 在适用的情况下，以数字方式检查装配顺序、拆卸路径、连接器插入路径、紧固件轴线、工具包络、端子访问、布线空间、弯曲半径和应变消除。将此证据标记为几何证据；不要声称物理配合、力或耐久性。
8. 在一次性副本上测试参数化可编辑性，然后恢复原始参数。
9. 导出所需的 STL 和 STEP 工件，并独立重新打开每个导出文件。
10. 渲染特写视图，分别显示和隐藏组件，以便可以审查原生开口和周围壁。
11. 渲染保存的 FCStd 文件，而不是近似的并行模型。
12. 完全按照运行器控制的方式运行每个仓库拥有的测试。

使用 run_inspect_fcstd.py 生成候选报告，然后使用以下命令将其与基线进行比较：

python scripts/compare_fcstd_reports.py --baseline <baseline-report.json> --candidate <candidate-report.json>

阅读 validation-matrix.md 以了解每个关口所需的证据。

5. 组装连贯的候选发布版本

1. 保持原生 CAD、嵌入源、导出文件、预览、布局、清单、快照、版本说明和活动索引相互一致。
2. 仅在最终工件生成后重新计算 SHA-256。在任何包含哈希的文件更改后重新运行验证。
3. 通过差异或存储的哈希来证明历史基线的不可变性。
4. 当项目策略禁止自动生成时，保持仅手动格式为空。
5. 当任何强制性关口未完成时，不要创建或批准标签或发布。
6. 当所需的数字关口通过时，允许进行图纸发布，即使可选的未来物理鉴定尚未运行。切勿将其标记为生产就绪或物理合格。
7. 仅在所需的物理构建、测量、组装和工程师签字通过后，从确切的图纸提交创建物理合格的产品发布。

阅读 release-lifecycle.md 以选择发布轨道和标签策略。在声明完成之前，请阅读 release-gate.md。

6. 如实报告

• 当所选发布轨道的所有任务要求的关口都通过时，返回 completed。
• 仅当权威任务或仓库源明确要求某个未完成的物理或操作员关口时，才返回 blocked 并保留已完成的候选者。
• 仅在证明请求的状态已经存在后，返回 no_change_needed。
• 将未请求的试样、循环、振动、引脚分配、布线或其他物理测试记录为后续建议，而不是阻塞项。不要捏造验收标准。
• 分别列出每个阻塞项，并附上证据和一项可操作的下一个步骤。
• 区分 not_run、failed 和 passed。切勿将缺乏证据转化为成功。
• 不要将发布阻塞项隐藏在风险或摘要文本中。