claw/docs/superpowers/specs/2026-04-17-scene-skill-60-to-90-roadmap-design.md

sgClaw Scene Skill 60-to-90 Roadmap Design

Status: Draft
Date: 2026-04-17
Author: Codex

Problem Statement

sg_scene_generate 与配套 runtime 已从单点原型演进为 scene skill 平台雏形，已具备以下基础能力：

• Scene IR
• workflowArchetype 分类
• deterministic + LLM merge
• readiness / blocker / fail-closed
• scene registry / resolver / dispatch
• report-artifact / xlsx_report 通用后处理

但从业务结果看，自动生成质量仍普遍停留在“约 60 分”的层级：系统可以识别部分结构、生成基础 skill 包、阻断明显错误结果，但尚不能稳定重建 tq-lineloss-report 这类高质量 skill 所具备的业务语义。

这意味着当前核心问题已经不是“有没有 compiler”，而是：

compiler 可以工作，但输入给 compiler 的 Scene IR 仍然不够像真实业务。

现阶段系统已开始处理以下问题：

• 低质量 sceneId
• bootstrap 被 localhost 污染
• archetype 误判
• readiness fail-open

但仍未真正解决以下高价值缺口：

1. mode-specific request / response / column / normalize 语义恢复不足
2. paginated_enrichment 的主请求、补数请求、过滤和导出链无法稳定绑定
3. 原始场景里的 BrowserAction、跨页注入、宿主桥接和本地导出链没有被统一建模
4. 生成器仍偏向“信息抽取 + 模板填充”，而不是“证据驱动的工作流语义恢复”

因此，本方案的目标不是继续局部修补 prompt 或模板，而是将“场景 skill 自动生成”从 60 分水平提升到可支撑 tq 级自动编译的总体路线，并形成正式设计。

Execution Context

scene skill 转化面对的并非公网独立网页，而是运行在内网环境中的场景包。场景通常嵌入自研浏览器执行，而不是直接在通用浏览器中独立运行。

典型执行链如下：

1. 用户先登录浏览器中的统一平台
2. 统一平台聚合多个业务系统，并承载场景入口
3. 用户点击场景执行后，场景脚本再切换或登录到目标业务系统
4. 登录和上下文预热过程不一定全部显式发生在当前页面中，可能通过隐藏域、宿主接口、后台注入或浏览器管道能力完成

因此，源场景中的 index.html、js/ 和页面按钮只是整个执行链的一部分，而非完整运行时边界。后续 scene skill 自动转化必须将“场景源码 + 宿主浏览器能力 + 平台上下文 + 目标系统上下文”视为同一问题空间，不能继续将场景误建模为普通静态网页脚本。

Goal

在不推翻现有 Scene IR + compiler + runtime 架构的前提下，把 scene skill 生成能力从“结构可识别、结果可阻断”的 60 分阶段，提升到“业务语义可恢复、样板家族可稳定编译”的 90 分阶段。

具体目标如下：

1. 对代表性样板场景，可稳定恢复 mode matrix、requestTemplate、responsePath、columnDefs、normalizeRules、参数契约与 bootstrap 契约
2. 对简单单请求报表场景，可形成高通过率量产模板
3. 对复杂分页补数场景，至少能正确识别其工作流问题空间，并在证据不足时稳定 fail-closed
4. 让 scene skill 平台从“自动模板生成器”收敛为“带门禁的通用 scene skill 转化器”

Success Definition

本方案的阶段性成功标准，不再以“生成结果是否尽量接近某个参考 skill 的结构”作为唯一目标，而是以通用场景生成后的 skill 能否在内网环境中直接运行、拿到正确数据并产出正确报表作为主判定口径。

阶段性成功至少同时满足以下三层闭环：

1. 执行闭环成立，即生成 skill 可在自研浏览器承载的内网环境中完成执行
2. 数据闭环成立，即查询、分页、提取后的数据结果正确且完整
3. 产物闭环成立，即生成的 Excel 或其他报表符合业务规则

因此，本轮路线优先面向“单系统、单页面、查询条件明确、分页拉全、按规则生成报表”的通用报表场景。特殊场景、工具型场景和高复杂 workflow 场景不要求在第一轮全部跑通，但必须被正确识别、分类并按边界处理。

Non-Goals

1. 不承诺一步覆盖全部 102 个场景
2. 不承诺对任意历史场景做到 100% 一次性自动命中
3. 不在本轮方案中解决登录恢复、认证兼容、浏览器宿主差异等全部运行环境问题
4. 不把 BrowserAction 跨页执行链完整抽象到第一阶段
5. 不把所有复杂文档渲染、模板上传、附件解析场景纳入 P0
6. 不在本轮方案中展开“统一平台登录 + 目标业务系统后台登录”的自动恢复实现细节，但必须把这类宿主执行前提显式建模

Current Landscape

全量场景结构判断

对 D:\desk\智能体资料\全量业务场景\一平台场景 的通读表明：

• 一共约 102 个场景目录
• 绝大多数具有统一入口 index.html
• 技术壳子高度同质化，主流是 Vue2 + jQuery + ElementUI
• 常见依赖包括 vue.js、jquery.js、elementui.js、moment.js、dpage.min.js
• 常见桥接脚本包括 ami.js、mca.js、/a_js/YPTAPI.js
• 页面结构通常为“工作信息 + 执行过程日志 + 历史报告 + 一键执行”的自动化工作台

这些场景并非 102 种完全不同的技术结构，而是少数几种前端场景包模板在不同业务上的复用。

场景包结构流派

1. 单文件内联型

典型：95598、12398、流程超期风险工单明细

特征：

• 顶层几乎只有一个 index.html
• 大量业务逻辑直接内联在页面内的 new Vue({...})
• 适合做源码内联语义提取样板

2. 标准静态包型

典型：台区线损大数据-月_周累计线损率统计分析

特征：

• 结构通常为 index.html + css/ + js/ + images/
• 业务逻辑拆分在 js/ 目录
• 线损 / 电量分析类核心样板大多属于这一流派

3. 模板 / 导出增强型

典型：供电可靠检修计划报表

特征：

• 目录包含 assets/、html/、copy/、docx/xlsx 模板文件
• 不只是查数，还带文档渲染、模板处理、Excel/Word 导出

4. 带历史副本的重包型

典型：力禾动环系统巡视记录

特征：

• 带 .history/、fsdownload/、多个 index*.html
• 含历史版本、下载副本、调试残留
• 是后续自动提取的高噪声来源

系统分布特征

高频系统和域名包括：

• yx.gs.sgcc.com.cn
• yxgateway.gs.sgcc.com.cn
• south.95598.sgcc.com.cn
• pms30.gs.sgcc.com.cn:32003
• 20.76.57.61:18080
• 10.4.39.180
• 多个 20.* / 21.* / 25.* / 10.* 内网 IP 系统

同时，大量场景依赖：

• localhost:13313
• localhost:13311
• localhost:13312

这表明大量场景并非纯业务页面，而是混合了：

• 业务 API 链
• 浏览器页面逻辑
• 宿主桥接
• 本地导出 / 本地服务

Host Browser Runtime Context

localhost:13313、localhost:13311、localhost:13312 以及 ws://localhost:12345 这类地址，在当前问题域中不应被简单视为错误业务域或无意义噪声。结合 多核浏览器管道API接口文档 可知，这些地址主要属于自研浏览器宿主提供的本地桥接能力，用于承接页面与浏览器内核、隐藏域、本地服务之间的通信。

结合现有文档与场景结构，宿主浏览器至少提供以下能力：

• websocket 管道通信
• 隐藏域页面打开与加载完成回调
• 指定域执行 JS
• 浏览器侧 ajax 代理
• 登录初始化与退出
• 主界面 / 隐藏域 / agent 区域切换
• 本地服务路径获取与导出相关能力

因此，localhost:* 不应继续直接归类为 bootstrap domain 或主业务 endpoint，而应识别为 host runtime dependency 或 browser bridge capability 证据：既要从“目标业务域识别”中剥离，又不能从“运行时依赖识别”中抹掉。

后续自动转化链需要同时区分三类对象：

• 真实业务目标域，如 yx.gs.sgcc.com.cn
• 宿主浏览器桥接域，如 localhost:*、浏览器 websocket、本地服务
• 场景自身页面与静态资源

若这三类对象继续混合建模，系统将持续出现 bootstrap 错判、workflow 误归因和 readiness 过宽放行。

Scene Family Segmentation

基于对 102 个场景目录命名、页面结构、前端依赖和页面壳子形态的归纳，可将当前场景集合收敛为 5 个实施家族，而不是 102 种彼此独立的技术问题。

Segmentation Result

当前 102 个场景可分为：

1. 通用单页报表组：68
2. 多模式报表组：11
3. 分页明细补数组：10
4. 工具检测前置组：8
5. 低优先级噪声组：5

Segmentation Interpretation

G1 + G2 + G3 共 89 个场景，约占全部样本的 87%。这表明当前主流问题空间仍然是报表型 scene skill 转化，而不是工具型、治理文档型或高噪声边界场景。

这一定义直接带来三点结论：

1. 总体路线应优先围绕报表型场景建立稳定 archetype，而不是先为边界场景设计通用超级框架
2. G4 虽不是当前主战场，但与后续 200+ 纯 JS 检测类场景存在结构亲缘，应在架构上预留
3. G5 不应进入首轮主线，而应作为降级识别与 fail-closed 的边界样本

Implementation Mapping by Scene Family

G1 通用单页报表组

定位：

• 当前覆盖率主力组
• 最接近“单系统、单页面、查询条件明确、分页或统计后导出报表”的通用场景定义

推荐 archetype：

• single_request_table
• wrapped_single_mode

推荐阶段：

• P1

主要目标：

• 形成高通过率量产模板
• 证明通用报表类具备规模化迁移能力

代表场景：

• 售电收入日统计
• 高低压新增报装容量月度统计表
• 供电可靠率指标统计表
• 光伏用户超容情况报表
• 供电服务工单业务统计表

主要验收点：

1. 查询条件可恢复
2. request / response contract 可恢复
3. 数据抽取正确
4. 报表导出正确
5. 同家族场景具备可复用性

G2 多模式报表组

定位：

• 当前能力上限验证组
• 用于证明生成器是否具备 tq 级业务语义恢复能力

推荐 archetype：

• multi_mode_request

推荐阶段：

• P0

主要目标：

• 验证多模式报表的模式矩阵、模式切换语义和模式内 contract 恢复能力

代表场景：

• 台区线损大数据-月_周累计线损率统计分析
• 用户日电量监测
• 线损同期差异报表

主要验收点：

1. 模式矩阵恢复
2. 模式切换语义恢复
3. 不同模式下 request / response contract 恢复
4. 列定义和 normalize 规则恢复
5. 内网执行后报表结果正确

G3 分页明细补数组

定位：

• 当前复杂 workflow 风险控制组
• 用于建立分页、明细、补数和 fail-closed 的识别边界

推荐 archetype：

• paginated_enrichment

推荐阶段：

• P1

主要目标：

• 建立复杂 workflow 识别和 fail-closed 能力

代表场景：

• 95598工单明细表
• 故障明细
• 重复致电（敏感）客户信息明细表

主要验收点：

1. 主链、分页链、补数链拆分正确
2. 明细拉全正确
3. 导出链识别正确
4. 证据不足时稳定 fail-closed

G4 工具检测前置组

定位：

• 当前非报表主线的前置组
• 用于为后续 200+ 检测类场景预留宿主执行能力

推荐 archetype：

• embedded_page_tool
• page_exec_check

推荐阶段：

• P2

主要目标：

• 预留页面内 JS 执行、宿主桥接识别和非报表结果采集能力

代表场景：

• 文件自动采集
• 计量数据助手
• 巡视计划完成情况自动检索

主要验收点：

1. 页面内 JS 执行能力可建模
2. 宿主桥接依赖可识别
3. 非报表型结果可采集

G5 低优先级噪声组

定位：

• 当前首轮主线外的边界组

推荐阶段：

• 降级处理

处理策略：

1. 优先识别而不是适配
2. 能 fail-closed 的优先 fail-closed
3. 不拿该组场景定义主线 archetype

Why Current Quality Stops Around 60

现阶段系统已能提取：

• sceneId
• sceneName
• endpoint
• 分页变量
• 部分过滤表达式
• archetype
• readiness 风险

但这些能力仍停留在“信息抽取”层，尚未进入“工作流语义恢复”层。

当前质量停留在 60 分附近的根因主要有五类：

1. 目标对象仍偏浅
   系统能识别 URL、函数名、分页字段，却不能稳定恢复 mode matrix、request contract、response contract

2. 缺少中间证据层
   当前 deterministic、LLM、compiler 三方结果仍然过于直接地汇入 Scene IR，缺少可裁决的语义证据层

3. archetype 约束仍偏粗
   能识别 multi_mode_request 或 paginated_enrichment，但还不能稳定证明“为什么成立”“最少哪些证据成立”

4. 业务链与宿主链未彻底分离
   localhost、导出接口、BrowserAction、静态资源、模板噪声仍容易污染 bootstrap 和 workflow 推断

5. 运行时语境没有被显式建模
   当前生成链仍偏向把场景理解成“页面源码 + 接口抽取”，但真实执行依赖统一平台、自研浏览器、隐藏域登录、宿主 ajax 和本地桥接能力。运行时语境一旦缺席，就会把宿主桥接误判为业务主链，或者把本应依赖宿主环境的场景误判为可独立运行 skill

What 90 Means

本方案中的“90 分”并不指所有场景均可自动跑通，而是指自动生成器开始具备 tq 级业务语义恢复能力。

一个场景 skill 只有同时满足以下能力，才可视为进入 90 分区间：

1. 参数契约可恢复
2. 模式切换语义可恢复
3. 每个模式的请求模板可恢复
4. 每个模式的响应提取路径可恢复
5. 列定义与归一化规则可恢复
6. 页面上下文和目标域名校验存在
7. 产物输出结构稳定
8. 失败时能给出业务级原因或稳定 fail-closed

Design Principles

1. 从“信息抽取器”升级到“工作流语义恢复器”

生成器不能继续停留在“抽 URL、抽函数名、抽字段”的层级，而必须恢复：

• 业务入口语义
• 参数契约语义
• 模式切换语义
• 请求构造语义
• 响应提取语义
• 行归一化语义
• 工作流语义
• 本地 / 宿主依赖语义

2. 先沉淀证据，再归约 Scene IR

目标主链为：

源码 -> 语义证据层 -> 证据归并/冲突消解 -> Scene IR -> compiler

而不是：

源码 -> LLM 总结 -> Scene IR -> compiler

3. fail-closed 优先于 fail-open

对复杂场景，证据不完整时应降级为 draft 或分析报告，而不是伪装成 runnable skill。

4. archetype 必须由工作流证据驱动

multi_mode_request、single_request_table、paginated_enrichment 的成立条件必须由最小工作流证据集支撑，而不是由表面关键词命中支撑。

5. 先做家族标准答案，再做规模化迁移

路线不追求起步即覆盖 102 个场景，而是先打穿少量高价值样板家族，再复制到同类场景。

6. 先分离宿主层与业务层，再做 archetype 与 Scene IR 归约

生成器必须把以下三层信息显式分离：

• 业务语义层
• 宿主浏览器能力层
• 本地服务 / 导出 / 登录桥接层

业务语义层负责识别目标系统、参数契约、模式切换、请求构造、响应提取和产物结构。宿主浏览器能力层负责识别隐藏域加载、JS 注入、浏览器 ajax 代理、标签页或区域切换等执行机制。本地服务 / 登录桥接层负责承载统一平台登录、目标系统后台登录、本地导出和宿主 websocket 通信等依赖。

若三层继续混合建模，系统将反复出现三类错误：误把 localhost 当 bootstrap domain，误把宿主桥接当业务 workflow，误把缺少宿主能力的场景判成可独立运行的 skill。因此，未来 Scene IR 或其前置证据层必须先完成分层，再进入 archetype 判断和 compiler。

Target Architecture

scene source
  -> source scan
  -> semantic evidence extraction
  -> evidence stratification
  -> evidence merge / conflict resolution
  -> archetype contract gating
  -> Scene IR
  -> compiler
  -> runtime compatibility check
  -> readiness grading
  -> runnable skill or fail-closed report

Required Semantic Recovery Domains

后续建设必须围绕以下 8 类语义恢复域展开：

1. 业务入口语义
2. 参数契约语义
3. 模式切换语义
4. 请求构造语义
5. 响应提取语义
6. 行归一化语义
7. 工作流语义
8. 本地 / 宿主依赖语义

P0 / P1 Sample Strategy

P0 样板组合

P0 不追求覆盖面，而是分别证明：

• 能力上限
• 规模稳定性
• 复杂 workflow 识别正确性

P0 样板固定为：

1. 台区线损大数据-月_周累计线损率统计分析
2. 用户日电量监测
3. 95598工单明细表

P0-1：台区线损大数据-月_周累计线损率统计分析

定位：

• multi_mode_request.month_week_table
• tq 主样板

Canonical Benchmark Mapping

台区线损大数据-月_周累计线损率统计分析 是 tq-lineloss-report 的原始场景来源。tq-lineloss-report 在本路线中不是普通参考 skill，而是第一份用于衡量“tq 级业务语义恢复能力”的 canonical benchmark。

该场景的自动转化目标不应停留在“生成一个可运行 skill 包”，而应尽可能逼近 tq-lineloss-report 已经体现出的关键业务语义，包括：

• month / week 模式矩阵
• 每种模式的请求契约与响应契约
• 列定义、归一化规则与导出语义
• bootstrap 与目标系统上下文约束

后续对自动生成质量的评估，应优先比较其与 tq-lineloss-report 的关键语义契合度，而不是只看是否产出了 runnable artifact。

Benchmark Role Clarification

tq-lineloss-report 是已完成“场景 -> skill -> 内网跑通”的高质量参考样板，但不是本方案中的唯一硬标准答案。后续自动生成结果不要求机械复制 tq-lineloss-report 的全部表现形式，而是要求在关键业务语义、内网可执行性与报表正确性上达到同等级别。

因此，tq-lineloss-report 在本方案中的作用是：

1. 证明“场景 -> skill -> 内网跑通”路线可行
2. 为多模式报表场景提供高质量语义恢复参考
3. 为 P0-1 提供业务级对照基线，而不是唯一输出模板

它的意义：

• 证明系统能否恢复 mode matrix
• 直接对标现有 tq-lineloss-report

P0-2：用户日电量监测

定位：

• single_request_table / wrapped_single_mode
• 单请求量产样板

它的意义：

• 证明系统可以让简单报表家族形成高通过率

P0-3：95598工单明细表

定位：

• paginated_enrichment.list_detail_filter_export
• 分页补数预研主样板

它的意义：

• 证明系统至少能正确识别复杂 workflow，并在证据不足时 fail-closed

P1 家族扩展

线损 / 电量多模式家族

• 白银线损周报
• 线损同期差异报表
• 线损大数据-窃电分析
• 供电所线路电量统计
• 台区零度户月度用电量与台区线损电量对比核查报表

单请求报表家族

• 售电收入日统计
• 高低压新增报装容量月度统计表
• 电能表现场检验完成率指标报表
• 供电可靠率指标统计表
• 光伏用户超容情况报表

分页补数家族

• 95598、12398、流程超期风险工单明细
• 故障明细
• 重复致电（敏感）客户信息明细表
• 营销业务管控监测日报表

Minimal Implementation Roadmap

Roadmap Prioritization Rationale

由于 G1 + G2 + G3 已覆盖 102 个场景中的绝大多数，因此路线优先级不按业务部门划分，而按场景家族划分。

首轮优先顺序固定为：

1. 先以 G2 多模式报表组验证语义恢复上限
2. 再以 G1 通用单页报表组验证规模化迁移能力
3. 再以 G3 分页明细补数组验证复杂 workflow 与 fail-closed

G4 作为后续检测类扩展的前置组保留，G5 不进入首轮主线。

阶段 1：打通 tq 主样板

主场景：

• 台区线损大数据-月_周累计线损率统计分析

最关键的三个里程碑：

1. 稳定恢复完整 mode matrix
2. 建立参数契约闭环
3. 让编译结果与手工 tq skill 结构同构

阶段 2：做单请求量产模板

主场景：

• 用户日电量监测

最关键的三个里程碑：

1. 稳定恢复 request / response / normalize 三件套
2. 压缩伪通用兜底主路径
3. 证明同家族单请求场景可复用

阶段 3：做分页补数的正确识别与阻断

主场景：

• 95598工单明细表

最关键的三个里程碑：

1. 正确拆开主链、补数链、导出链
2. 建立 paginated_enrichment 最小可编译证据集
3. 在证据不足时稳定 fail-closed

Three Global Preconditions

在进入上述三阶段前，必须先满足三个总前置里程碑：

1. 建立可裁决的语义证据层
2. 建立最小可编译业务契约
3. 冻结 P0 样板标准答案

Precondition 1: Semantic Evidence Layer

最小必须落地的对象：

1. 统一证据对象 schema
2. 核心证据类型集合
3. 证据归并规则
4. 证据到 Scene IR 的映射边界

最小证据类型集合建议包括：

• bootstrap_candidate
• endpoint_candidate
• mode_candidate
• request_template_candidate
• response_path_candidate
• column_defs_candidate
• normalize_rules_candidate
• workflow_candidate
• localhost_dependency_candidate
• browser_action_candidate
• export_candidate

Precondition 2: Minimal Compilable Business Contract

最小必须落地的对象：

1. archetype 最小契约表
2. 契约 gate 列表
3. 阻断规则
4. archetype 最小输出契约

统一 gate 名称至少包括：

• bootstrap_resolved
• request_contract_complete
• response_contract_complete
• workflow_contract_complete
• runtime_contract_compatible

Precondition 3: P0 Canonical Answers

最小必须落地的对象：

1. 三个 P0 样板的标准 Scene IR
2. 三个样板的关键证据清单
3. 三个样板的验收标准
4. 三个样板的失败 taxonomy

Acceptance Criteria

本方案完成的标志不是“所有场景都能生成 skill”，而是以下条件成立：

1. tq 主样板能稳定恢复 mode matrix，并产出与手工版高度同构的结果
2. 单请求主样板能稳定恢复 request / response / normalize 三件套，并可扩展到同家族多个场景
3. 分页补数主样板能稳定识别其问题空间，并在证据不足时稳定 fail-closed
4. Scene IR 前存在可裁决的语义证据层，而不是直接靠全文总结进 compiler
5. archetype 有明确最小可编译业务契约，生成器不会继续伪造 runnable skill

Risks

1. 若继续直接强化 prompt 而不补证据层，质量提升会很快撞到上限
2. 若没有最小可编译契约，compiler 仍会继续吞入“看起来像 business IR、实际证据不闭合”的结果
3. 若没有固定 P0 标准答案，后续回归和迁移验证会失去校准基线
4. 分页补数家族若过早当作主战场，极易把 localhost、导出链、宿主链再次污染到 bootstrap 和 workflow

Open Questions

1. 证据层是否作为独立 Evidence IR 引入，还是先以内嵌字段方式扩充当前 Scene IR
2. localhost_dependency_candidate、browser_action_candidate、export_candidate 是否第一版就纳入硬门禁
3. P0 标准答案是否需要单独固化为 fixture + golden IR 双份基线
4. 对复杂分页补数场景，第一阶段是否允许生成 draft skill，还是一律只出分析报告

G1 Boundary Refinement

本轮整改后，G1 不再表示“所有看起来像报表的场景”，而是收敛为“单系统、单主请求、可直接恢复请求契约与表格契约的通用单页报表家族”。

G1 仅允许承接以下结构：

1. 单系统、单主页面承载，主流程不依赖复杂宿主桥接。
2. 存在可识别的主查询入口，且请求模板、响应路径、字段列定义可以直接恢复。
3. 结果主体为单表或单次汇总，不依赖本地落库后二次分析。
4. 输出主形态为直接表格结果、Excel 结果或等价的单次数据汇总。

出现以下任一特征时，应直接排除出 G1：

1. 业务主链路依赖 BrowserAction、sgBrowserExcuteJsCode 或同类宿主桥接接口推进。
2. 页面依赖多轮 callback / 子请求串联才能补全最终结果。
3. 同一场景内存在多个业务 endpoint 的分类盘点、分桶汇总或接口扫数。
4. 报表生成前需要本地落库、SQL 聚合、二次分析或文档拼装。
5. 输出主结果不是直接表格，而是抓取后再生成 Word/专题文档等二段式产物。

在此基础上，G1 增加一个上边界子型：G1-E 轻量补查汇总型。该子型仍属于 G1，但允许“单主请求 + 少量补查请求”的轻度扩展，前提是主查询契约仍清晰、最终输出仍以单次汇总表为主，且补查链路不升级为宿主桥接多步 workflow。

Family Reassignment

基于第一轮真实样本迁移与结构复核，以下 4 个边界样本的归属已经冻结，不再继续作为普通 G1 样本混用：

样本场景	原暂挂位置	正式归属	重排原因摘要
高低压新增报装容量月度统计表	G1 候选	G1-E 轻量补查汇总型	主查询仍存在，但页面同时包含少量补查接口；更适合作为 G1 上边界样本，而非纯 single_request_table。
电能表现场检验完成率指标报表	G1 候选	G6 宿主桥接多步查询型	主链路依赖 BrowserAction / sgBrowserExcuteJsCode 与 callback 串联，多步查询特征明确。
计量资产库存统计	G1 候选	G7 多接口盘点汇总型	页面通过多个资产统计 endpoint 分类型扫数，属于多接口盘点汇总，而非单请求表格恢复。
95598供电服务月报	G1 候选	G8 抓取落库分析出文档型	先抓取数据，再经 localhost 落库与 SQL 分析，最后产出文档，结构上已超出报表直生家族。

为避免后续家族边界再次漂移，本设计同时冻结这 4 个新旧家族的最小定义：

1. G1-E 轻量补查汇总型 主查询清晰、补查轻量、最终仍可归并为单次汇总结果。
2. G6 宿主桥接多步查询型 业务查询必须经宿主桥接接口推进，且存在显式多步 workflow 或 callback 串联。
3. G7 多接口盘点汇总型 页面通过多个 endpoint 分项拉取后再统一汇总，核心难点是接口分组、口径对齐和聚合拼装。
4. G8 抓取落库分析出文档型 页面抓取只是前置阶段，后续还存在本地存储、SQL 分析或文档生成链路。

Implementation Impact

这次边界整改的直接影响不是“增加几个名字”，而是调整后续实现顺序、验证口径和 gate 策略。

首先，single_request_table 不再承担所有“看起来像报表”的兜底职责。对于证据落入以下结构的场景，编译器应优先 fail-closed，而不是继续伪装成可运行的 G1 skill：

1. 宿主桥接主导型。
2. 多 endpoint 盘点汇总型。
3. 本地落库再分析型。

其次，后续实现顺序固定为：

1. 先做 G1-E
2. 再做 G6
3. 再做 G7
4. 最后做 G8

该顺序的原因是：

1. G1-E 与现有 G1 能力距离最近，最适合作为边界收紧后的第一步。
2. G6 需要先解决宿主桥接与 workflow 证据建模问题。
3. G7 需要在 G6 之后单独处理多接口分组与聚合逻辑。
4. G8 依赖抓取、落库、分析、出文档的完整后链路，复杂度最高，放在最后更稳妥。

最后，这一整改会同步改变后续验收口径：

1. G1 的验收重点从“是否生成了 skill”改为“是否恢复出完整且自洽的主请求契约”。
2. 边界样本不得再以 single_request_table 生成成功作为通过标准。
3. 新家族未落地前，相关样本应输出明确的家族归属和阻断原因，而不是继续产出低质量伪 runnable skill。