向振动线 / 研发取料单（v0.1，2026-09-17）

要什么：六层链那四步脚本的源码，以及两件"标准答案"产物（任一份历史产出即可）。 为什么：观澜包内只有编排壳、没有实现 —— scripts/windcms.py analyze 会去调 scripts/rudong_tcm_oem_scan.py / rudong_line_energy_share.py / rudong_model_run.py / rudong_fusion_run.py，这四个脚本没随包，所以六层链在目标机上一步也跑不动 （实测：can't open file 'scripts/rudong_model_run.py'）。 接口不用重新讨论：壳里已经写死了每步怎么调、吃哪个环境变量（见 docs/振动六层链_接口规格与缺口_v0.1.md §1），照现在的调用约定实现即可，我们不改壳。

一、要的四件（脚本）

#	要的东西	现状	拿到后解锁
1	`scripts/rudong_tcm_oem_scan.py`	缺	轴承/齿轮/保持架/叶片 1P 的特征频率扫描（约 23 件扫描件可从"✗ 无生成端"转成"✓ 已在重算链上"）。★ 只要一句话也能推进：在理论特征频率附近怎么取观测峰（带宽 ±?% / 按幅值还是能量取最大 / 是否插值 / 是否按 rpm 阶次跟踪 / 多记录怎么合并）—— 分母（理论频率表 + 转速换算）包内已齐、比值语义已确认，缺的只有这一步（见规格书 §7）
2	`scripts/rudong_line_energy_share.py`	缺	线能量占比（对应产物名待你确认，包内未见同名件）
3	`scripts/rudong_model_run.py`	缺	`model_run_l6.parquet` + `model_run_summary.json`（六层模型的第六层出件）
4	`scripts/rudong_fusion_run.py`	缺（本包已逆向实现了一件，见下）	`fusion_38.csv` + `fleet_scalar_z.parquet` 等融合面产物

★ 第 4 件部分已自研：fleet_scalar_z.parquet 的口径已反推并在包内实现（scripts/rudong_fusion_run.py）——val 逐值 100% 一致、基线公式（median + 1.4826×MAD）在正确行集上 100% 一致。还差的只是"样件行集为什么少 276 行"，有了原件（或下面第 6 件）一眼就能判定。所以第 4 件若一时给不出源码，只给一件 fusion_38.csv 也行。

二、要的两件（标准答案）

#	要的东西	为什么非要它	拿到后怎么验收
5	`model_run_l6.parquet` 任一份历史产出	这是 `model_run` 步的标准答案。没有它，反推出来的实现无法证明是"复现"还是"另一个算法"（本项目的硬规矩：允许响亮降级，不许造数）	放进 `outputs/<场>/m5_cms_tcm/` 后跑 `python scripts/rudong_fusion_run.py --verify`（同口径的对拍器）或按 §三逐值对拍
6	`fusion_38.csv` 任一份历史产出	同上，且它能让 `fleet_scalar_z` 的行集疑问当场结案（同一次融合的产物，行集应当一致）	同上

三、接到料之后怎么验收（照抄即可）

# ① 四个脚本是否就位（本包自带检查器）
python scripts/chain_gap_check.py --check

# ② 六层链能不能跑（先只跑扫描/建模/融合，不碰报告）
python scripts/windcms.py analyze --window w0316 --steps oem_scan energy_share model_run fusion

# ③ 融合面逐值对拍（口径已反推，只查行集）
python scripts/rudong_fusion_run.py --verify

# ④ 反查台账：哪些件从"✗ 无生成端"转成"✓ 呼应成立"
python scripts/products_reverse_audit.py --check
python scripts/products_restore_missing.py --refresh     # 台账账实相符

通过判据（不含糊）：

chain_gap_check --check 退出码 0（四件脚本 + 两件样件都在位）；
② 各步 rc=0，且 outputs/<场>/m5_cms_tcm/ 出现 model_run_l6.parquet / fusion_38.csv；
③ 逐值 100% 一致（val/fleet_med/z 三列都不许有 1e-4 以上的偏差）；对不上就不许替换样件；
④ products_reverse_audit 里 vib_handoff_and_scans 的 ✗ 件数应从 36 降到个位数。

四、我们这边的承诺

不改壳、不改接口：四步脚本放回 scripts/ 即可被 windcms.py analyze 调用（参数与环境变量见规格书 §1）。
件到位才转正：对拍未通过前，相关件一律留在"✗ 无生成端"并如实显示缺件；绝不用"看起来对"的近似产物顶替（这条已经在 rudong_fusion_run.py --verify 里做成机器判据）。
收到料的当期：把验收结果（对拍一致率、行集差异、剩余未知）写回 docs/振动六层链_接口规格与缺口_v0.1.md 与 docs §13.6 的自动块，便于下次交接。

五、追加一件（2026-09-17 查证后新增）

#	要的东西	为什么	证据
7	2026-01 的 CMS decode 导出件（`*_decode.json`，即 w0127 窗的源件）	`blade_1p_records.parquet`（叶片 1P，662 行）的时间跨度是 2026-01-27 11:35 ~ 2026-02-01 23:16，而本机 `data/raw/如东/windcms/` 下只有 `CMS_RuDong_CGN_202603-04`（3–4 月） ⇒ 1 月窗的谱库在本地重建不了，连"拿 `a1P` 试候选峰值口径"的场地都没有	本机实测：`w0127` 索引（随包件 `m5_cms_tcm/tcm_index.parquet`）在，330,308 行、2026-01-27 ~ 2026-02-03、含样件那批记录（同一时间戳 89 行）；但它的源件导出不在 `data/raw`。谱库只有 w0316（3–4 月）那一份

⇒ 也就是说，1P 这一族要收口，需要两样外部输入：（a）峰值拾取口径（第 1 项那句话）与（b）1 月的 decode 导出件（本项）。两样都到位后，动作是确定的：rudong_tcm_index.py → rudong_tcm_spectra.py（只转 FFT_4_Tr 这类低频谱即可，不必 --meas ALL）→ 用 scripts/spectra_lookup.py 取幅值 → 与样件 a1P 逐值对拍。 | 8 | 其余 5 个窗的 CMS 导出件（w0707 / w0711 / w0724 / w0805 / w0811，即 2026-07、08 月的 decode 件） | 三张扫描表的样件覆盖这 6 个窗，而本机只有 3-4 月（CMS_RuDong_CGN_202603-04）的源件 ⇒ 即使拿到口径，也只能复现 w0127（若第 7 项的 1 月件到位）与 w0316，其余 5 窗无法重建（索引与谱库都不在） | 实测：四张表的 window 取值 = w0127/w0707/w0711/w0724/w0805/w0811；data/raw/如东/windcms/ 只有 3-4 月 |

向振动线取料单_v0.1.md 6.3 KB История Директен файл