# 修复记录 2026-10-21（凌晨，Trae 积分耗尽后由本地 harness 接手）

## 已修复

### 1. 半精/精加工进给过低（306 分钟 → 预计 ~46 分钟）
- **根因**：`parameters.json` 的 SpeedFeedTable 里「铝合金-精铣」档是 Vc=94 m/min、fz=0.02 齿
  （D8 → S3740 / F299.2），比粗加工（Vc 240 / fz 0.12 → F4583.7）慢得离谱。
- **做法**：不改 rule_engine（保评测基线），新增阶段覆盖机制
  - `data\std\stage_overrides.json`：`{"N": {"semi": {"vc":250,"fz":0.05}, "finish": {"vc":250,"fz":0.05}}}`
  - `tools\stage_override.py`：按 vc/fz 反算 rpm=1000vc/(πD)、feed=rpm×fz×z，附来源标记
  - `tools\stage_gen.py`：在 return 前注入调用（备份 `stage_gen.py.bak_*`）
- **实测效果（N 铝 / D8）**：
  ```
  修复前：semi rmp=3740.1 feed=299.2   （F 只有粗的 1/15）
  修复后：semi rpm=9947.2 feed=1989.4  （来源 stage_override(N/semi)）
  预计：306 分钟 → ~46 分钟（约 6.6 倍）
  ```
- **门禁**：443→445 个 .py 0 错误、评测 21/21、漂移 0、测试 19/19 全过（基线未破）

### 2. 自检误报「重复刀路 99.5%」
- **根因**：5mm 网格遇上 3.83mm 中位段长 → 网格饱和，格点被反复计数
- **做法**：`tools\nc_check.py` 判定条件加 `cut_seg_shorter_than_grid_ratio < 0.5`，
  饱和时不再计入告警（文件已有 0.1mm 容差的「真重复」判据可用）
- **实测**：A01 自检从「1 致命 + 2 告警」变为「0 致命 + 1 告警（抬刀 216 次，真实）」

### 3. 刀号 T0（已不存在，现场复核）
- 最新程序实测：`(T3=D12 ... H03 ...)`、`(T5=D8 ... H05 ...)` —— **非 T0，已有补偿号**
- 之前报告的 T0 来自 10-20 早些时候的旧文件；重新生成后已消失
- 仍备有 `tools\nc_toolfix.py`：需要重映射刀号时用（`--map "D12=1,D8=2"`，带 .bak 备份与 dry-run）

## 未修复（附原因与下一步）

### 4. 层间斜进刀（ramp）未落地
- 现状：`gen_templates.py` 里 `TransferBetweenLevelsTypes = Direct`（层间直下）
- 影响：每层直插，抬刀/入刀不够平滑；A01 实测抬刀 216 次
- 原因：NX2412 的 `TransferBetweenLevelsTypes` 枚举里是否有 Ramp 未实测；
  且改后需重新生成 `NXAI_工序模板.prt`（约 40 秒 NX 运行）并逐项读回验证
- 下一步：跑一次枚举探测（`dir(TransferBetweenLevelsTypes)`），有 Ramp 就替换并重生成

### 5. NX 侧写刀号的 API 未通
- 探测脚本 `tools\probe_tool_number.py` 在 NX2412 上失败：
  `OpenBaseDisplay` 返回 tuple → `part.CAMSetup` 报 AttributeError；
  `CreateCamSession` 触发 `memory access violation`
- 结论：不要在这个 API 上继续试；刀号通过 `nc_toolfix.py` 在 NC 层处理（已验证可用）

### 6. 后处理注册（需管理员，未执行）
- `tools\post_register_local.bat` 已就绪（会备份 template_post.dat、写三条 NXAI_*_FANUC）
- 现在 NX 里仍是旧条目（3Zdbzq/4Zdbzq，NX2412 打不开或不出 A）
- 需人工右键管理员运行一次，然后用含 A 轴工序 + NXAI_4AX_FANUC 验证 `A90.` 出现

## 本次改动文件清单
```
新增  data\std\stage_overrides.json
新增  tools\stage_override.py
新增  tools\nc_toolfix.py
新增  tools\probe_tool_number.py（探测失败，留作记录）
修改  tools\stage_gen.py（注入阶段覆盖，已备份）
修改  tools\nc_check.py（网格饱和判定，已备份）
```

## 追加修复：发布站漏更新（2026-10-21 10:00）

### 现象
`https://ldeh.asia/files/` 上的 `NXAI_工序模板.prt` 是旧版（11 模板），
而本地已是新版（15 模板）；两者**大小恰好都是 241,024 字节**，但 sha256 不同。

### 根因
`tools\site_publish.py` 的 blob 复制判断用的是**文件大小**：
```python
if not (blob.exists() and blob.stat().st_size == src.stat().st_size):
    shutil.copy2(src, blob)
```
大小相同 → 判定"没变" → 跳过复制；`posts.json` 里记的 sha256 是旧文件的，
上传时又因 size 相同被跳过（SFTP 侧同样按 size 判断）→ 站点一直是旧文件。

### 修复
两处都改成 **sha256 比对**：
1. 本地 blob 复制：`need = sha256_of(blob) != sha256_of(src)`
2. `posts.json` 重新生成时按真实 sha256 落库（原本就带 sha，只是文件没更新导致不一致）

### 验证
```
修复前  工序模板: 站点 sha=809cc454...  本地不同 → 不一致 ❌
修复后  工序模板: 站点 sha=d4959e8e...  与本地一致 ✅
        刀具库:   两处一致 ✅（原本就对）
```

### 教训（写进清单）
```
⚠ 判断"文件是否变化"必须用内容哈希，不能用大小/时间戳
   大小相同、时间戳可能被复制保留 → 都会漏更新
⚠ 同类风险点：packaging.py 的增量判断、cloud_sync.py 的 SKIP 判断
   已在 cloud_sync 里用 sha256（正确）；packaging 每次全量打包（无此问题）
```