claw/docs/superpowers/reports/2026-04-18-g1-e-p0-validation-report.md

# G1-E P0 Validation Report

> Date: 2026-04-18
> Scope: `docs/superpowers/plans/2026-04-18-g1-e-light-enrichment-report-plan.md` Phase 1 -> Phase 3
> Fixed Sample:
> - `D:\desk\智能体资料\全量业务场景\一平台场景\高低压新增报装容量月度统计表`

## 1. Conclusion

本轮 `G1-E` P0 验证已通过。

最终结果已经从误判的 `page_state_eval` 收敛为正式的 `single_request_enrichment`，并且真实样本生成结果中已经同时恢复出：

1. 主请求
2. 补查请求集合
3. 合并/汇总规则

这说明本轮 plan 的核心目标已经达成：系统不再只会“识别并拦截低质量生成物”，而是已经能对该 P0 样本恢复出可编译的 `G1-E` 三段式语义。

## 2. Validation Inputs

真实样本生成命令：

```powershell
cargo run --bin sg_scene_generate -- --source-dir "D:/desk/智能体资料/全量业务场景/一平台场景/高低压新增报装容量月度统计表" --scene-id g1e-capacity-monthly --scene-name "高低压新增报装容量月度统计表" --scene-kind report_collection --output-root "D:/data/ideaSpace/rust/sgClaw/claw-new/examples/g1e_p0_validation"
```

关键输出位置：

1. `examples/g1e_p0_validation/skills/g1e-capacity-monthly/references/generation-report.json`
2. `examples/g1e_p0_validation/skills/g1e-capacity-monthly/references/generation-report.md`
3. `examples/g1e_p0_validation/skills/g1e-capacity-monthly/scripts/collect_g1e_capacity_monthly.js`

## 3. Before vs After

整改前：

1. `workflowArchetype = page_state_eval`
2. `readiness.notes` 中记录的是 `workflow_archetype=page_state_eval`
3. 生成脚本走的是 `page_state_eval` / 简化脚本路径
4. 虽然已经提取到 `mainRequest / enrichmentRequests / mergePlan`，但 compiler 没有真正走 `G1-E` 专用编译路径

整改后：

1. `workflowArchetype = single_request_enrichment`
2. `generation-report.md` 明确显示 `Workflow archetype: single_request_enrichment`
3. 生成脚本已经包含：
   - `const MAIN_REQUEST =`
   - `const ENRICHMENT_REQUESTS =`
   - `const MERGE_PLAN =`
4. `readiness.notes` 已更新为 `workflow_archetype=single_request_enrichment`

## 4. Recovered Semantics

### 4.1 Main Request

已恢复主请求：

1. Endpoint: `getWkorderAll`
2. URL: `http://yxgateway.gs.sgcc.com.cn/emss-cmnf-common-front/member/workOrderQuery/getWkorderAll`
3. Request template:
   - `pageNo = 1`
   - `pageSize = 1`
4. Response path: `data`

### 4.2 Enrichment Requests

已恢复补查请求：

1. `queryElectCustInfo`
2. `queryBusAcpt`
3. `getBatchPerCust97`

其中补查入参绑定已经恢复出：

1. `appNo = ${row.wkOrderNo}`
2. `getBatchPerCust97` 额外固定参数：
   - `baseNewFlag = "01"`
   - `pageNo = 1`
   - `pageSize = 20`

### 4.3 Merge Plan

已恢复汇总语义：

1. Join key: `wkOrderNo`
2. Group rule: `group_by:countyCodeName`
3. 汇总附加规则：
   - `append_total_row`
   - `compute_share_columns`
4. 聚合规则：
   - `com:hightVolTotalThisMonth,hightPressureTotalThisMonth`
   - `com:lowVolTotalThisMonth,lowPressureTotalThisMonth`
   - `batchCom:lowVolTotalThisMonth,lowPressureTotalThisMonth`
   - `com:hightVolTotalOtherMonth,hightPressureTotalOtherMonth`
   - `com:lowVolTotalOtherMonth,lowPressureTotalOtherMonth`
   - `batchCom:lowVolTotalOtherMonth,lowPressureTotalOtherMonth`

### 4.4 Output Columns

最终输出列已非空，且恢复出完整统计口径，包含：

1. `index`
2. `countyCodeName`
3. `hightPressureTotalOtherMonth`
4. `hightVolTotalOtherMonth`
5. `lowPressureTotalOtherMonth`
6. `lowVolTotalOtherMonth`
7. `otherMonthShare`
8. `hightPressureTotalThisMonth`
9. `hightVolTotalThisMonth`
10. `lowPressureTotalThisMonth`
11. `lowVolTotalThisMonth`
12. `thisMonthShare`
13. `yearHightPressureTotal`
14. `yearHightVolTotal`
15. `yearLowPressureTotal`
16. `yearLowVolTotal`
17. `yearShare`

## 5. Root Cause And Fix

本次误判的直接原因不是证据缺失，而是 archetype 分类优先级错误。

真实样本同时存在以下噪音信号：

1. `branch_fields=reportType, mode, month`
2. `filters=res.status == 200`
3. 常见分页字段

旧逻辑要求：

1. 只有在 `!has_branch_fields` 时，才允许判为 `SingleRequestEnrichment`

这导致真实样本即使已经同时满足：

1. `has_g1e_main_endpoint`
2. `has_g1e_enrichment`
3. `has_g1e_merge_signal`

仍然会因为存在 `mode/reportType/month` 噪音而失去 `G1-E` 判定资格，随后又被 `status` 噪音吸入 `page_state_eval`。

本次修正后的口径是：

1. 只要 `G1-E` 三段式核心证据齐备，就优先判为 `single_request_enrichment`
2. 不再因为一般性的 `branch field` 噪音退化为 `page_state_eval`

## 6. Test And Verification Record

本轮执行的定向验证：

1. `cargo test --test scene_generator_test`
2. `cargo test --test scene_generator_modes_test`
3. `cargo test --test scene_generator_html_test`
4. `node --test tests/scene_generator_llm_test.js`

结果：

1. 以上 `scene generator` 定向测试全部通过
2. 真实 P0 样本复跑成功

补充说明：

1. `cargo test --workspace` 中存在两条与本次 `G1-E` plan 无关的既有失败：
   - `service::server::tests::deterministic_bootstrap_target_uses_plan_target_url`
   - `service::server::tests::bootstrap_target_precedence_matrix_covers_page_context_deterministic_skill_and_fallback`
2. 这两条失败不属于本次 plan 改动引入，也不阻塞本次 `G1-E` P0 验收

## 7. Acceptance Check

对照 plan 的 Phase 3 退出标准，当前状态如下：

1. 主请求、补查请求、合并规则均已稳定恢复
2. 结果不再是 `params=[] / requestEntries=[] / columnDefs=[]` 的空壳生成物
3. archetype 已不再退化为 `page_state_eval`
4. compiler 已实际走入 `G1-E` 专用路径

结论：

1. `docs/superpowers/plans/2026-04-18-g1-e-light-enrichment-report-plan.md` 的 Phase 1 -> Phase 3 已完成

## 8. Remaining Gap

本轮完成的是 `G1-E` P0 最小闭环，不代表已经达到“业务结果 100% 等价于人工高质量 skill”。

当前仍然保留的后续空间是：

1. 进一步提升字段中文标题编码质量
2. 继续验证 `G1-E` 第二个真实样本是否能复用同一语义恢复路径
3. 继续把 `G1-E` 与 `G6/G7/G8` 的越界判定做得更稳