feat: add generated scene skill platform hardening

docs/superpowers/reports/2026-04-18-lineloss-family-variant-grouping-report.md

@@ -0,0 +1,136 @@
+# 线损家族变体分组报告
+> Date: 2026-04-18
+> Scope: `docs/superpowers/plans/2026-04-18-lineloss-family-variant-expansion-plan.md`
+> Purpose: 完成 Phase 0 / Phase 1 交付物，冻结当前线损家族基线，并建立后续扩展分组清单。
+
+## 1. 当前已冻结基线
+
+本轮扩展以前，线损家族中已经可稳定识别并生成的子型为：
+
+1. `G2-A = g2_a_dual_mode_baseline`
+   代表样本：`台区线损大数据-月_周累计线损率统计分析`
+   特征：同一主链路下同时存在月 / 周两套模式，请求和列定义都较完整。
+2. `G2-B = g2_b_weekly_single_mode`
+   代表样本：`白银线损周报`
+   特征：仍属于线损主链路，但只有周报单侧模式，需要用最小周报合约兜住生成。
+3. `G2-C = g2_c_mixed_linked_workflow`
+   代表样本：`线损同期差异报表`
+   特征：主链路仍是线损查询，但同时联动外部系统或二次查询，只能先恢复主链路最小合约。
+
+上述三类已经在上一轮回归中通过本地测试，并在真实样本重生成为候选 skill，不再回退到“只修主样本”的阶段。
+
+## 2. 线损场景盘点结果
+
+本次从 `D:\desk\智能体资料\全量业务场景\一平台场景` 中筛出的线损相关场景为：
+
+1. `台区线损大数据-月_周累计线损率统计分析`
+2. `白银线损周报`
+3. `线损同期差异报表`
+4. `台区零度户月度用电量与台区线损电量对比核查报表`
+5. `线损大数据-窃电分析`
+6. `线路月度高负损预测`
+7. `台区线损台区月度高负损预测`
+8. `供电所线路电量统计`
+9. `线路失电信息明细`
+
+其中 `8` 和 `9` 与当前线损主家族相关度较弱，不纳入本轮优先扩展对象。
+
+## 3. 结构化分组
+
+### 3.1 已落地组
+
+1. `G2-A 双模式主报表型`
+   代表样本：`台区线损大数据-月_周累计线损率统计分析`
+2. `G2-B 周报单侧模式型`
+   代表样本：`白银线损周报`
+3. `G2-C 混合联动主链路型`
+   代表样本：`线损同期差异报表`
+
+### 3.2 新增候选组
+
+1. `G2-D 预测计算型`
+   代表样本：
+   - `线路月度高负损预测`
+   - `台区线损台区月度高负损预测`
+   结构特征：
+   - 页面内存在 `reportType = monthlyHighNegativeLossPredictionForLines` 或同类预测型标识
+   - 结果并非直接来自标准 `cols1/cols2` 表头，而是先读取多个输入表或数据块，再在页面内计算 `lineLossRate / powerLoss / lineLossType`
+   - 导出字段以“预测结果字段”为主，如 `lineId / lineName / lineLossType / lineLossRate / powerLoss`
+   结论：
+   - 这类不是传统 G2 主报表直接抽列，而是“取数 + 计算 + 导出”的计算型线损变体
+   - 适合优先扩展，因为有两个高度相似样本，可做成同一家族
+
+2. `G2-E 核查对比型`
+   代表样本：
+   - `台区零度户月度用电量与台区线损电量对比核查报表`
+   结构特征：
+   - 同时调用 `getUserElectricList` 与 `getTqLinelossInfoListRank`
+   - 页面内做数据拼接、按 `TG_NO / CONS_NO` 关联用户和台区数据
+   - 导出字段同时含台区维度和用户维度，如 `TG_NO / TG_NAME / consno / thisMonth / beforeMonth1`
+   结论：
+   - 该组更像“主链路 + 明细补查 + 拼接报表”
+   - 与 `G2-C` 有相似性，但最终产物比 `G2-C` 更偏“核查对比报表”而不是简单主链路恢复
+
+3. `G2-F 异常诊断 / 下钻型`
+   代表样本：
+   - `线损大数据-窃电分析`
+   结构特征：
+   - 先取 `getTqLinelossInfoListRank`
+   - 再调用 `tqAutoDiagnoseAnalyse/search`、`stealElecAnalyse/getFlqdyhDetailList`、`stealElecAnalyse/userVoltsAndElecflowMoniter/search`
+   - 页面中通过多次诊断接口拼装 `remark`
+   - 导出字段核心列为 `TG_NO / LOSS_PQ / LINELOSS_RATE / remark`
+   结论：
+   - 该组属于“线损主表筛选后进入异常诊断和明细下钻”的复合流程
+   - 二次、三次请求显著多于 `G2-C`，复杂度高于本轮已落地三类
+
+## 4. 本轮实施映射
+
+按当前 plan 的 Phase 3 约束，本轮只选择最容易形成“分组复制”的 1 到 2 个新增家族，不做全量铺开。
+
+优先级排序如下：
+
+1. `P0: G2-D 预测计算型`
+   原因：
+   - 有两个结构高度相似的真实样本
+   - 页面内计算逻辑清晰，字段也相对稳定
+   - 可以形成新的最小合约和新的 fixture 组
+2. `P1: G2-E 核查对比型`
+   原因：
+   - 虽然只有一个当前样本，但和现有 `G2-C` 最接近
+   - 适合作为“主链路 + 关联补查”方向的下一扩展
+3. `P2: G2-F 异常诊断 / 下钻型`
+   原因：
+   - 链路最长，remark 拼接和异常判断逻辑较重
+   - 适合放在本轮后半段，优先做候选验证而不是一步做满
+
+## 5. Phase 3 前置可行性结论
+
+在进入实际实现前，对 `G2-D` 两个真实样本再次核查后确认：
+
+1. `线路月度高负损预测`
+2. `台区线损台区月度高负损预测`
+
+这两类页面虽然具备稳定的预测结果字段和 `reportType`，但当前源码里几乎只体现为：
+
+1. 本地读表或页面内计算
+2. `localhost:13313` 导出与报表日志依赖
+3. 没有足够稳定的线损业务接口可抽成当前生成器的请求链路
+
+因此，本轮实现不强行把 `G2-D` 塞进现有请求驱动编译链，而是将其保留为“候选组”，等待后续补齐“本地计算 / 文件输入型 skill”能力后再做。
+
+据此，本轮实际实施顺序调整为：
+
+1. 先实现 `G2-E`
+2. 再实现 `G2-F`
+3. `G2-D` 暂停在候选验证阶段
+
+## 6. Phase 1 退出结论
+
+本轮线损扩展已经从“按单场景修补”切换到“按家族分组推进”：
+
+1. 已冻结 `G2-A/G2-B/G2-C` 基线，不再回头重做主样本修补。
+2. 已识别出后续新增的三个线损变体方向：`G2-D/G2-E/G2-F`。
+3. 经可行性核查后，本轮实际实现顺序固定为：
+   - 先做 `G2-E`
+   - 再做 `G2-F`
+   - `G2-D` 保留为下一阶段候选组