源代码化清单_v0.1.md 13 KB
源代码化清单 v0.1（2026-09-19）
用户令：「所有的计算 均要形成 观澜的源代码，确保 观澜 在别的电脑安装后，系统运行正常。」
本清单是这条令的可核对底稿：把"页面/接口要用的每一件数据，是不是都由包内的源代码算出来的"逐族列清， 列出还没落到源代码的那些族的现状、喂谁、缺什么、怎么补。
判据来源（机器可读，不靠印象）：scripts/products_reverse_audit.py::FAMILIES 的族表 ——
kind=shipped/human 且 gen=None 的族就是"没有生成端"；scripts/products_reverse_audit.py --check
在交付前会把族表与盘上账目对一遍（当前 rc=0：1,778 件全部 raw-derived）。
0. 已经补上源代码的（本令的前几批）
| 件 | 生成端（在包内） | 喂谁 | 复检 |
|---|---|---|---|
m5_cms_tcm/handoff_vibration_v2.json（融合面） |
scripts/rudong_fusion_handoff.py（观澜自算：报告状态等级 + fusion_38.csv + L6 过闸线 → 同结构件；meta.from 标"观澜自算"，盘上若有振动线正本则不覆盖） |
/detail/v2 的「需要关注」+「全场状态」（/api/fleet 的 fus） |
链盘 38 行 / 需要关注 3 台（WTG09 齿轮箱、WTG17/WTG27 发电机）/ 矩阵 38 行 ✔ |
windscada/index.html（总览「全场状态」页） |
scripts/windscada_overview_build.py（用组件同一个快照烘焙器 src/windscada/ui/snapshot.py::bake） |
/detail/v2 的「全场状态总览」<iframe src="/static/index.html"> |
3.78 MB 真页面（此前是 2 KB 的"产物不在位"说明页）✔ |
事实契约面：sop/findings.json + paradigm_r1 三份底稿 + guanlan/** |
scripts/sop_findings_from_ledger.py（重算台账 → claim，按契约构建器要的字段结构写）+ scripts/guanlan_facts_contract.py build（原有生成端，输入换成自算件） |
门户「本场结论·契约生成」段、/detail 问答/报告面（/api/facts）、报告摘要 |
/api/facts 200（cards 6）· 门户结论段 2.6 KB 换成 RD-LEDGER-*（6 条: 4 候选 / 2 参考）· 契约自检 PASS ✔ |
变桨面：pitch/pitch_daily.parquet + pitch/pitch_zero_monthly.parquet |
scripts/pitch_face_build.py（重算链 ④c：scada_10min 的开关量 timeon/压力锯齿/运行状态 + scada_1min 的三叶桨距角/压力/有功 → 日粒度表与零位三口径月表；口径/阈值/证据落在 pitch/pitch_face_manifest.json） |
/api/fleet 的变桨面四维度判级（逐台页/总览的"变桨系统"格）+ 依据行 |
日粒度 20,796 行/38 台 2025-01-01 → 2026-07-07（与旧随包件行数一致）；零位 zero_dev 停机顺桨段 + zero_dev_full 满发段 + zero_dev_run 运行段分档（判据轴，能把 19# 拎出来）；非零位列与旧件相对一致率 99.9% ✔ |
链上：④b（model_run → fusion → report → fusion_handoff → kb）→ ⑤b 由重算台账生成 claim → ⑤c 构建+渲染契约 → ⑤a 台账维护 → ⑤ 审计 → … → ⑦b 总览页自算烘焙 → ⑧b 重装门户。
claim 六族（全部由重算产物算，逐条带 coverage/缺证据/证伪判据，相对判据封顶「候选」）：
报警集中（alarms）· 重复检修（workorders）· 停机损失集中（loss_monthly，kWh→MWh 已换算）·
温度相对离群（temp_bins，样本门 n≥20）· 功率曲线偏离（powercurve_dev，MW→kW 已换算 + 判别分布）·
振动面过闸线（model_run_l6）。
1. 还没落到源代码的族（按"装了新机器会不会看到空白"排序）
| # | 族 | 件 | 喂谁（页面/接口） | 现在没源代码的后果 | 需要的生成端（输入 → 产物） | 可行性 |
|---|---|---|---|---|---|---|
pitch_shipped |
pitch/pitch_daily.parquet、pitch_zero_monthly.parquet |
— | — | 已解决（见 §0 / §2）：scripts/pitch_face_build.py，族表已从 pitch_shipped(shipped) 改成 pitch_face(raw-derived) |
✅ 完成 | |
vib_handoff_and_scans 其余件 |
m5_cms_tcm/component_history.json、baseline_38.json（oem_frequency_scan.parquet 等扫描件仍随包） |
— | — | 已解决：scripts/component_history_build.py（链 ④d）+ scripts/baseline_38_build.py（链 ④e），族表新族 vib_history_baseline(raw-derived) |
✅ 完成 | |
| 3 | tcm_replay |
tcm_compatible_replay/model/mask_thresholds.tsv 等 |
CMS 报告/逐台页的厂商黄红阈值线；data.load_masks |
页面只画机群中位，阈值线缺失（现文案："厂商未设阈值"） | 由 data/raw/如东/windcms 导出件里的 red_alarm/yellow_alarm/red_hys/… 索引列反解出每 (测点,测量,工况) 的中位/黄/红标量 |
中偏低：索引里确有这些列（54 列之一），口径需反推 + 抽台对拍 |
| 4 | ontology_releases |
ontology/release_r1/*、release_r2/* |
网关 /release/*（只读发布层）、门户"发布层"入口 |
/release/ 两件 503（如实报缺） |
由 ontology/objects.json + 层清单配置生成 r1/r2 层（kb_ingest/populate 之后跑一步） |
易：纯搬运/投影，无判据 |
| 5 | guanlan_contract + sop_workspace + paradigm_r1 |
— | 门户结论段 / /api/facts / 报告 |
已解决（见 §0）：由重算台账生成 claim | — | ✅ 完成 |
| 6 | windcms_pages 剩余件 |
windcms/ 下厂家报告转录、kb 之外的其他件 |
CMS 首页/工作台的少数入口 | 个别入口空 | 多数已由 windcms.py report/kb 覆盖；剩余是"厂家报告转录"（输入是现场 PDF，属外部正本） |
易/不适用 |
| 7 | vib_figs |
m5_cms_tcm/figs/* |
振动报告里的插图 | 报告少图 | 由谱库渲染 PNG（可复用 src/windcms 的 SVG/绘图） |
低优先 |
| 8 | windscada_pages 剩余件 |
windscada/turbines/*、review/* |
静态副本（运行期逐台页由组件动态出，不依赖它） | 无实际影响 | 若要静态副本：复用 windscada_overview_build.py 的烘焙（逐台 slim 版） |
易 |
| 9 | human_deliverables |
windscada/mblub_alarm_cross.json、review_presented.json、送审结论 |
本体 populate 的证据来源之一 |
少一条人工证据（本体仍可用） | 不应由源代码生成（是人对人的交证件/回执） | 不适用（族表已记 kind=human，不参与呼应校验） |
2. 变桨面（已完成；口径 = 用户令选定的停机段中位 + 满发段中位两者分列出）
生成端：scripts/pitch_face_build.py（重算链 ④c，约 10 分钟：逐台读 10min + 1min 全量 ≈ 28 GB 中的
两路所需列）。产物自登记进 _derived_manifest.json；族表 pitch_face（kind=raw-derived）。
消费者字段契约（src/windscada/subsys/pitch.py::load/registry，改动需同步）：
pitch/pitch_daily.parquet date, turbine, n, hydlevel_timeon, hydfilt_timeon, hyd_band,
hyd_over_relief, hyd_under_pump, hublub_timeon, pitchpum_timeon,
pistA, pistB, pistC, n_op, hyd_mean
pitch/pitch_zero_monthly.parquet month, turbine, zero_dev ← 消费端读这一列 (=停机顺桨段口径)
+ zero_dev_stop / zero_dev_full ← 用户令要求的两口径**分列**
(停机顺桨段 / 满发段)
+ zero_dev_run, run_bins ← ★第三口径: 运行段**同工况分档**
(判据轴; 反推旧件后补, 见下)
+ stop_med, full_med, n_stop, n_stop_all, n_full,
spread_stop, spread_full, base_stop, base_full ← 原始量与基准(可核对)
pitch/pitch_face_manifest.json 口径 / 阈值 / 证据 / 跳过与未出值清单
通道勘察（data/raw/如东/scada_10min 表头实测，38 件表头一致、597 列）：
din_wtc_HydLevel_timeon / din_wtc_HydrFilt_timeon 油位/滤网开关 on 秒 (=当日应测 n×600 − timeon → 报警秒)
din_wtc_LubPistA/B/C_counts 三叶柱塞动作次数 (pistA/B/C)
dot_wtc_HubLubPu_timeon / dot_wtc_PitchPum_timeon 轮毂润滑泵 / 变桨泵 (段内秒数求和)
prs_wtc_HydPress_min|max|mean 液压系统压力 (蓄能器锯齿): 段内 (max−min) 中位 = 52bar
flg_wtc_ScInOper_endvalue 运行段判据 (n_op)
零位两口径的取数（1min 数据，经 scada_source：CSV 优先 / MDB 回落）：
pitch_angle_blade_1/2/3 + active_power + rotor_speed（+ 液压站预充压力 供越线计数）；
· 停机段中位 = 该月「顺桨停机」分钟（转速 < 0.5 rpm ∧ |有功| < 50 kW ∧ 三叶桨距角中位 ∈ 顺桨带
[85,92]°）三叶桨距角中位 − 同月全场中位基准；
· 满发段中位 = 满发（有功 ≥ 95% 额定 = 3800 kW）分钟的三叶桨距角中位 − 同一基准。
两个口径按月×台分列输出；zero_dev 取停机段，另一口径并列可见（依据行都写）。
★第三口径（反推旧件后补，是真正的判据轴）：zero_dev_run = 运行段（转速 ≥ 0.5 rpm ∧ 有功
100~3800 kW）按有功 500 kW 分档，逐档与同月全场同档中位比，再取该台跨档中位。为什么必须有它 ——
拿旧交付包里的随包件与现场专项对拍（只作结构/量级对照，数值不搬）：
① 旧件 zero_dev 只有 19# 是离群（全期 −0.896°，其余 37 台中位 ≈0）⇒ 其口径是"绝对零位偏差"，
与本器"相对同月全场中位"不同源，故零位一族不做逐值对拍；
② 本器停机顺桨段口径把 19# 读成 +0.11°（顺桨止挡是机械硬基准，fleet 集中在 88.59~88.69°±0.7°，
差异被止挡抹平 ⇒ 量不出运行区零位差）；满发段 19# = +0.61° 且台间离散大（混风况）；
③ 运行段分档口径把 19# 单独拎出来（逐月持续为负、其余台 ≈0）—— 与现场「19# 零位 −0.87° 专项确诊」
定性一致。
⇒ 结论（用户令 2026-09-19 裁决：维持此口径）：pitch.py D3 判据按"停机段与运行段取更不利"
（§3.2 同一纪律），依据行三个数都写出来。判据轴 = 运行段同工况分档（zero_dev_run），
停机顺桨段（zero_dev）按用户令照旧分列、照旧参与"取更不利"；要改判据轴只动 pitch.py 一处，
并同步本节与该生成端的口径注释。
★实测逮到的坑（写进生成端注释与 manifest）：停机分钟的桨距角是双峰 —— WTG01 2025-01 停机分钟的 5/25/50/75/95 分位 = 28.7 / 31.2 / 31.79 / 88.59 / 88.63°（一半顺桨、一半停在 ~31.8° 未顺桨位）。 不按带滤的话，中位会在两支间跳（2025-01 得 31.79°、2025-04 得 88.66°），基准就没了物理含义。
★非零位列的对拍（同一次生成端复检里做的逐值比对）：pitchpum/hydlevel/hydfilt_timeon 与 pistA/B/C
相对一致率 99.9%、hyd_band 95.4%、hyd_mean 同量级（212.6 vs 212.6 bar）⇒ 10min 侧口径复现无误；
n_op 旧件口径未知（WTG01 2025-01-01 旧 48 / 本器 61 运行段），只作量级对拍。
3. 需要你定的（其余口径）
（第 5 行的事实契约口径已按你的选择落地；第 1 行的变桨零位口径也已按你的选择"两口径分列"落地。） 目前没有待你裁的口径项了；剩余各族按 §4 顺序推进即可。
4. 执行顺序（修订）
① ontology_releases 生成端（易，点亮 /release 两件） ✅ 完成 (scripts/ontology_release_build.py)
② tcm_replay 掩码阈值反解（中偏低） ✅ 完成 (scripts/tcm_mask_thresholds_build.py)
③ pitch 面生成端（中，口径已定；消费者字段契约见 §2） ✅ 完成 (scripts/pitch_face_build.py)
④ component_history / baseline_38 生成端（中） ✅ 完成 (scripts/component_history_build.py / baseline_38_build.py)
⑤ vib_figs / 静态逐台副本（低优先） ← 剩余（低优先；页面运行期动态出页，静态副本无实际影响）
本批之后的账：scripts/products_reverse_audit.py --check = rc=0（1,800 件产物全部 raw-derived、
0 件无生成端、0 件未归类、0 条判据失败）；docs/系统设计说明.md §13.6 的自动块已随之重写。
每补一族都走同一套纪律：生成端进包 + 进重算链 + 写进族表(gen/input) + 产物自登记 + 复检页面，
并把该族在族表与 docs/系统设计说明.md §13.6 里从"无生成端"改成"已在重算链上（附口径与验证依据）"。