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接口文档](D:/data/ideaSpace/rust/sgClaw/claw-new/docs/多核浏览器管道API接口文档.docx) 可知，这些地址主要属于自研浏览器宿主提供的本地桥接能力，用于承接页面与浏览器内核、隐藏域、本地服务之间的通信。

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

- 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

```text
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。