213 lines
5.2 KiB
Markdown
213 lines
5.2 KiB
Markdown
# G1-E Light Enrichment Report Plan
|
|
|
|
> Date: 2026-04-18
|
|
> Status: Draft
|
|
> Source:
|
|
> - `docs/superpowers/specs/2026-04-18-g1-e-light-enrichment-report-design.md`
|
|
> - `docs/superpowers/specs/2026-04-17-scene-skill-60-to-90-roadmap-design.md`
|
|
> - `docs/superpowers/reports/2026-04-18-g1-boundary-reassignment-report.md`
|
|
|
|
## 1. Plan Intent
|
|
|
|
本计划用于把 `G1-E 轻量补查汇总型` 从概念边界推进到可实施状态。
|
|
|
|
本轮只解决一个问题：
|
|
|
|
1. 让生成器能够对“单主请求 + 少量补查 + 单次汇总输出”的场景，恢复出可编译的三段式业务语义。
|
|
|
|
本计划不处理 `G6/G7/G8`，也不扩展到其它家族。
|
|
|
|
## 2. Scope
|
|
|
|
本计划纳入范围的对象只有三类：
|
|
|
|
1. `G1-E` 证据层补齐
|
|
2. `G1-E` 三段式 `Scene IR` / compiler gate 落地
|
|
3. `高低压新增报装容量月度统计表` 的 P0 样板验证
|
|
|
|
本计划明确排除：
|
|
|
|
1. `G6 宿主桥接多步查询型`
|
|
2. `G7 多接口盘点汇总型`
|
|
3. `G8 抓取落库分析出文档型`
|
|
4. `102` 个场景的大规模家族扩展
|
|
|
|
## 3. Fixed Sample
|
|
|
|
本计划的唯一 P0 样板固定为：
|
|
|
|
1. `高低压新增报装容量月度统计表`
|
|
|
|
该样板的冻结目标是：
|
|
|
|
1. 主请求：`getWkorderAll`
|
|
2. 补查请求：
|
|
- `queryElectCustInfo`
|
|
- `queryBusAcpt`
|
|
- `getBatchPerCust97`
|
|
3. 最终恢复为主请求、补查请求、并回规则三段式结构
|
|
|
|
在本计划完成前，不新增第二个 `G1-E` 样板。
|
|
|
|
## 4. Phase Overview
|
|
|
|
执行顺序固定为：
|
|
|
|
`Phase 0 -> Phase 1 -> Phase 2 -> Phase 3`
|
|
|
|
### Phase 0: Freeze Contract
|
|
|
|
目标：
|
|
|
|
1. 冻结 `G1-E` 最小定义
|
|
2. 冻结 P0 样板的主链、补查链、并回链目标口径
|
|
|
|
必须落地的对象：
|
|
|
|
1. `G1-E` spec
|
|
2. P0 样板目标结构说明
|
|
3. 失败分类口径
|
|
|
|
退出标准：
|
|
|
|
1. 后续实现不再回退成普通 `G1 single_request_table`
|
|
|
|
### Phase 1: Evidence Layer Completion
|
|
|
|
目标：
|
|
|
|
1. 让提取链路可以显式产出 `main_request` 证据
|
|
2. 让提取链路可以显式产出 `enrichment_request` 证据
|
|
3. 让提取链路可以显式产出 `merge_plan` 证据
|
|
|
|
必须落地的对象：
|
|
|
|
1. `main_request` 证据 schema
|
|
2. `enrichment_request` 证据 schema
|
|
3. `merge_plan` 证据 schema
|
|
4. 对应的越界识别信号
|
|
|
|
退出标准：
|
|
|
|
1. P0 样板不再只落到 `page_state_eval`
|
|
2. 提取结果中能看见主请求、补查请求、并回规则候选
|
|
|
|
### Phase 2: Scene IR And Compiler Gates
|
|
|
|
目标：
|
|
|
|
1. 在 `Scene IR` 中承载三段式结构
|
|
2. 在 compiler 中增加 `G1-E` 专属 gate
|
|
3. 防止缺失补查契约的结果误判为普通 `G1` 成功
|
|
|
|
必须落地的对象：
|
|
|
|
1. `main_request`
|
|
2. `enrichment_requests[]`
|
|
3. `merge_plan`
|
|
4. `main_request_resolved`
|
|
5. `enrichment_requests_resolved`
|
|
6. `merge_plan_resolved`
|
|
7. `g1e_scope_compatible`
|
|
|
|
退出标准：
|
|
|
|
1. `G1-E` 可以独立于 `single_request_table` 被判定
|
|
2. 越界样本会被阻断，而不是伪成功
|
|
|
|
### Phase 3: P0 Validation
|
|
|
|
目标：
|
|
|
|
1. 用 `高低压新增报装容量月度统计表` 验证 `G1-E` 最小闭环
|
|
2. 冻结第一版验收基线
|
|
|
|
必须落地的对象：
|
|
|
|
1. P0 样板生成结果
|
|
2. P0 样板验证记录
|
|
3. P0 样板失败归因记录
|
|
|
|
退出标准：
|
|
|
|
1. 主请求、补查请求、并回规则均能稳定恢复
|
|
2. 结果不再是空壳 `params=[] / requestEntries=[] / columnDefs=[]`
|
|
3. 缺证据时能 fail-closed
|
|
|
|
## 5. Work Breakdown
|
|
|
|
### Task Group A: G1-E Evidence Modeling
|
|
|
|
任务目标：
|
|
|
|
1. 定义主请求证据对象
|
|
2. 定义补查请求证据对象
|
|
3. 定义并回规则证据对象
|
|
4. 明确越界到 `G6/G7/G8` 的识别信号
|
|
|
|
完成标志：
|
|
|
|
1. `G1-E` 不再依赖“全文像不像报表”的模糊判断
|
|
|
|
### Task Group B: G1-E IR / Compiler Integration
|
|
|
|
任务目标：
|
|
|
|
1. 为 `G1-E` 建立三段式 `Scene IR`
|
|
2. 增加 `G1-E` gate
|
|
3. 切断“补查缺失但仍按普通 G1 成功”的通道
|
|
|
|
完成标志：
|
|
|
|
1. `G1-E` 与 `G1` 的成功条件正式分离
|
|
|
|
### Task Group C: P0 Sample Verification
|
|
|
|
任务目标：
|
|
|
|
1. 重新生成 `高低压新增报装容量月度统计表`
|
|
2. 核对主请求、补查请求、并回规则是否完整
|
|
3. 输出验证报告
|
|
|
|
完成标志：
|
|
|
|
1. `高低压新增报装容量月度统计表` 成为 `G1-E` 第一版标准样板
|
|
|
|
## 6. Deliverables
|
|
|
|
本计划完成时至少产出：
|
|
|
|
1. `G1-E` 证据层实现
|
|
2. `G1-E` 三段式 `Scene IR`
|
|
3. `G1-E` compiler gate
|
|
4. `高低压新增报装容量月度统计表` 的 P0 生成与验证结果
|
|
5. 对应整改报告或验证报告
|
|
|
|
## 7. Acceptance Criteria
|
|
|
|
本计划完成的标志是：
|
|
|
|
1. `G1-E` 已从文档定义进入可实现、可验证状态
|
|
2. `高低压新增报装容量月度统计表` 不再被误生成为普通 `G1` 空壳 skill
|
|
3. 生成器能够显式恢复：
|
|
- 主请求
|
|
- 补查请求
|
|
- 并回规则
|
|
4. 当证据不足或结构越界时，系统会阻断并说明原因
|
|
|
|
## 8. Execution Guardrails
|
|
|
|
执行过程中必须遵守以下边界：
|
|
|
|
1. 不把 `G6/G7/G8` 的能力提前混入 `G1-E`
|
|
2. 不扩展第二个 `G1-E` 样板
|
|
3. 不为了“先生成一个 skill”而放松 gate
|
|
4. 不把 `G1-E` 再退化回普通 `single_request_table`
|
|
|
|
## 9. Next Plan
|
|
|
|
本计划完成后，后续顺序固定为：
|
|
|
|
1. 若 `G1-E` P0 验证通过，再决定是否补第二个 `G1-E` 样板
|
|
2. 然后再进入 `G6` 的独立 spec / plan
|