332 lines
8.5 KiB
Markdown
332 lines
8.5 KiB
Markdown
# G2 家族整改计划
|
||
|
||
> **Status:** Draft
|
||
> **Date:** 2026-04-18
|
||
> **Author:** Codex
|
||
> **Upstream Spec:** [2026-04-18-g2-remediation-design.md](D:/data/ideaSpace/rust/sgClaw/claw-new/docs/superpowers/specs/2026-04-18-g2-remediation-design.md)
|
||
|
||
## Plan Intent
|
||
|
||
本计划用于把 `G2` 家族整改设计拆解为可执行任务，目标是把当前线损多模式报表家族从“信号能抓到但主链重建失败”，推进到“至少第一份样本达到候选验证门槛”。
|
||
|
||
本计划严格限定在 `G2` 家族整改，不扩展到：
|
||
|
||
1. `G1`
|
||
2. `G3`
|
||
3. 更大范围真实场景迁移
|
||
4. 登录恢复、宿主协议重构或运行时 transport 改造
|
||
|
||
## Success Baseline
|
||
|
||
整改阶段的最低成功口径固定为：
|
||
|
||
1. `台区线损大数据-月_周累计线损率统计分析` 不再坍缩为 `paginated_enrichment`
|
||
2. 至少该样本能生成 `multi_mode_request` 结构
|
||
3. `bootstrap` 落到线损主业务承载面
|
||
4. `modes` 至少恢复 `month` 与 `week`
|
||
5. mode-specific `request/response/column/normalize` 合同不再为空
|
||
6. readiness 不再在核心合同缺失时给出虚高 `A`
|
||
7. 样本结果达到“可进入候选验证”门槛
|
||
|
||
## Scope Guardrails
|
||
|
||
执行过程中保持以下边界不变：
|
||
|
||
1. 不切换到 `G1/G3` 样本执行
|
||
2. 不继续补更多同类 `G2` 观察样本
|
||
3. 不在本计划中展开内网人工验证
|
||
4. 不在本计划中处理统一登录与隐藏域登录恢复
|
||
5. 不发散到 scene skill 平台通用重构
|
||
|
||
## Target Samples
|
||
|
||
本计划整改与回归只围绕以下三份 `G2` 样本：
|
||
|
||
1. `台区线损大数据-月_周累计线损率统计分析`
|
||
2. `白银线损周报`
|
||
3. `线损同期差异报表`
|
||
|
||
对应产物路径：
|
||
|
||
1. `examples/real_scene_batch_round1/skills/real-tq-lineloss-report-r1`
|
||
2. `examples/real_scene_batch_round1/skills/real-baiyin-lineloss-weekly-r1`
|
||
3. `examples/real_scene_batch_round1/skills/real-lineloss-period-diff-r1`
|
||
|
||
## Workstreams
|
||
|
||
本计划拆为五条工作流，与上游 `spec` 一一对应：
|
||
|
||
1. `WS1` G2 archetype 纠偏
|
||
2. `WS2` bootstrap 纠偏
|
||
3. `WS3` mode contract 重建
|
||
4. `WS4` endpoint 去污染
|
||
5. `WS5` readiness 收紧
|
||
|
||
## Phase Overview
|
||
|
||
本计划按四个阶段推进：
|
||
|
||
1. Phase 0：冻结整改基线
|
||
2. Phase 1：修正识别与选择
|
||
3. Phase 2：重建 `G2` 合同
|
||
4. Phase 3：回归真实样本并产出整改报告
|
||
|
||
执行顺序固定为：
|
||
|
||
`Phase 0 -> Phase 1 -> Phase 2 -> Phase 3`
|
||
|
||
其中 `Phase 1` 先于 `Phase 2`，避免在错误 archetype 和错误 bootstrap 上继续堆模板逻辑。
|
||
|
||
## Phase 0：冻结整改基线
|
||
|
||
### Objective
|
||
|
||
把当前 `G2` 家族首轮 blocker、对标口径和验收门槛冻结，避免整改过程中边界漂移。
|
||
|
||
### Tasks
|
||
|
||
1. 固化三份 `G2` 样本的当前失败画像
|
||
2. 固化 `tq-lineloss-report` 作为 `G2` 主锚点参考
|
||
3. 固化 `G2` 候选验证门槛
|
||
4. 固化整改阶段只围绕 `G2` 的边界
|
||
|
||
### Deliverables
|
||
|
||
1. 本计划
|
||
2. 已存在的 `G2` blocker 汇总
|
||
3. 已存在的第一轮迁移与候选验证报告
|
||
|
||
### Exit Criteria
|
||
|
||
1. 后续执行不再追加同类 `G2` 观察样本
|
||
2. 不再用“先去内网试试”替代整改闭环
|
||
|
||
## Phase 1：修正识别与选择
|
||
|
||
### Objective
|
||
|
||
先把 `G2` 主链判定修正过来，解决 archetype、bootstrap 与 endpoint 污染这三个上游问题。
|
||
|
||
### WS1：G2 Archetype Rectification
|
||
|
||
#### Task 1
|
||
|
||
审计当前 `G2` archetype 误判来源，确认：
|
||
|
||
1. 哪些分页信号在夺权
|
||
2. 哪些 mode 信号没有进入主判定
|
||
3. 当前 `multi_mode_request` 与 `paginated_enrichment` 的优先级冲突点在哪里
|
||
|
||
#### Task 2
|
||
|
||
修改 `G2` archetype 判定逻辑，使以下信号在 `G2` 中具备更高权重：
|
||
|
||
1. `month/week`
|
||
2. `mode`
|
||
3. `tjzq`
|
||
4. 同一场景内多组线损接口
|
||
5. 模式切换分支字段
|
||
|
||
#### Task 3
|
||
|
||
新增或更新回归测试，证明：
|
||
|
||
1. 当前 `G2` fixture 不再判成 `paginated_enrichment`
|
||
2. `G2` 相关修正不会误伤现有 `G3` fixture
|
||
|
||
### WS2：Bootstrap Rectification
|
||
|
||
#### Task 4
|
||
|
||
审计当前 bootstrap 选择逻辑，确认为什么三份样本都稳定落到 `20.77.115.36:31051`。
|
||
|
||
#### Task 5
|
||
|
||
为 `G2` 引入更严格的 bootstrap 选择约束：
|
||
|
||
1. 优先真实线损业务承载页
|
||
2. 排除页面壳入口与错误主域
|
||
3. 继续排除 `localhost:*`、第三方库 URL、静态资源 URL
|
||
|
||
#### Task 6
|
||
|
||
新增或更新测试，证明：
|
||
|
||
1. `G2` 主样本 bootstrap 不再落到错误入口
|
||
2. `localhost:*` 仍只作为宿主依赖证据保留
|
||
|
||
### WS4：Endpoint Purification
|
||
|
||
#### Task 7
|
||
|
||
审计当前 endpoint 提取污染来源，明确以下类别如何被误收进业务候选：
|
||
|
||
1. 第三方依赖库
|
||
2. 文档外链
|
||
3. 静态资源 URL
|
||
4. 其他业务系统遗留接口
|
||
|
||
#### Task 8
|
||
|
||
收紧 endpoint 候选过滤与排序规则，使 `G2` 样本中：
|
||
|
||
1. 线损主业务接口排在前列
|
||
2. 外链与依赖库 URL 不再进入主业务候选
|
||
3. 其他业务系统 endpoint 不再轻易抢占主链
|
||
|
||
#### Task 9
|
||
|
||
补充测试，证明：
|
||
|
||
1. `G2` 主 endpoint 排序明显改善
|
||
2. 噪声 endpoint 不再污染生成主脚本
|
||
|
||
### Phase 1 Exit Criteria
|
||
|
||
1. `G2` fixture archetype 判定修正
|
||
2. `G2` bootstrap 选择修正
|
||
3. `G2` endpoint 候选排序修正
|
||
|
||
## Phase 2：重建 G2 合同
|
||
|
||
### Objective
|
||
|
||
在主链判定正确后，恢复 `G2` 必需的 mode-specific 合同与更严格的 readiness。
|
||
|
||
### WS3：Mode Contract Reconstruction
|
||
|
||
#### Task 10
|
||
|
||
为 `G2` 定义最小 mode contract，至少包括：
|
||
|
||
1. `modes[]`
|
||
2. `defaultMode`
|
||
3. `modeSwitchField`
|
||
4. per-mode `requestTemplate`
|
||
5. per-mode `responsePath`
|
||
6. per-mode `columnDefs`
|
||
7. per-mode `normalizeRules`
|
||
|
||
#### Task 11
|
||
|
||
修改 `Scene IR` 组装或生成逻辑，让 `G2` 样本在证据充分时真正输出 `modes[]`，而不是只保留空壳默认字段。
|
||
|
||
#### Task 12
|
||
|
||
修改 `G2` 生成脚本模板或编译路径，避免继续退化成通用：
|
||
|
||
- `paginate -> secondary_request -> filter`
|
||
|
||
要求生成结果能体现：
|
||
|
||
1. `month` 模式
|
||
2. `week` 模式
|
||
3. 不同模式的请求差异
|
||
4. 不同模式的列差异
|
||
|
||
#### Task 13
|
||
|
||
新增或更新测试，证明：
|
||
|
||
1. `台区线损大数据-月_周累计线损率统计分析` 可输出非空 `modes`
|
||
2. 至少一个 `G2` fixture 恢复出 mode-specific contract
|
||
|
||
### WS5：Readiness Tightening
|
||
|
||
#### Task 14
|
||
|
||
为 `G2` 新增或收紧 gate，至少覆盖：
|
||
|
||
1. `g2_archetype_resolved`
|
||
2. `g2_bootstrap_resolved`
|
||
3. `g2_modes_present`
|
||
4. `g2_request_contract_complete`
|
||
5. `g2_response_contract_complete`
|
||
|
||
#### Task 15
|
||
|
||
调整 readiness 评级逻辑，保证以下情况不再给出高等级：
|
||
|
||
1. `modes = []`
|
||
2. `requestTemplate = null`
|
||
3. `columnDefs = []`
|
||
4. archetype 误判
|
||
|
||
#### Task 16
|
||
|
||
新增或更新测试，证明：
|
||
|
||
1. 不闭合 `G2` 样本会被降级或阻断
|
||
2. readiness 与候选验证门槛一致
|
||
|
||
### Phase 2 Exit Criteria
|
||
|
||
1. 至少 `G2` 主样本拥有可解释的 mode contract
|
||
2. readiness 不再虚高
|
||
3. `G2` 生成结果在结构上具备进入候选门槛的可能
|
||
|
||
## Phase 3：回归真实样本并产出整改报告
|
||
|
||
### Objective
|
||
|
||
在整改完成后，重新生成三份 `G2` 真实样本，并输出第二轮正式结论。
|
||
|
||
### Tasks
|
||
|
||
#### Task 17
|
||
|
||
重新生成以下三份 `G2` 样本：
|
||
|
||
1. `台区线损大数据-月_周累计线损率统计分析`
|
||
2. `白银线损周报`
|
||
3. `线损同期差异报表`
|
||
|
||
#### Task 18
|
||
|
||
按与第一轮完全一致的口径，对比以下项目：
|
||
|
||
1. archetype
|
||
2. bootstrap
|
||
3. modes
|
||
4. request contract
|
||
5. response / column / normalize contract
|
||
6. readiness
|
||
|
||
#### Task 19
|
||
|
||
输出整改后的第二轮报告，至少包含：
|
||
|
||
1. 哪些 blocker 被修掉
|
||
2. 哪些 blocker 仍存在
|
||
3. 哪些样本进入候选验证名单
|
||
4. 哪些样本仍需 fail-closed
|
||
|
||
### Deliverables
|
||
|
||
1. 第二轮 `G2` 真实样本生成结果
|
||
2. 第二轮 `G2` 整改回归报告
|
||
3. 更新后的候选验证名单
|
||
|
||
### Acceptance Criteria
|
||
|
||
1. `台区线损大数据-月_周累计线损率统计分析` 至少进入候选验证名单
|
||
2. 三份样本不再统一坍缩成 `paginated_enrichment`
|
||
3. readiness 与真实业务闭合程度基本一致
|
||
|
||
## File-Level Targets
|
||
|
||
本计划执行时，至少会触达以下类型资产：
|
||
|
||
1. `src/generated_scene/` 下的 analyzer / generator / readiness 相关实现
|
||
2. `tests/fixtures/generated_scene/` 下的 `G2` fixture 或 canonical 资产
|
||
3. `tests/` 下与 scene generator / canonical / readiness 相关的回归测试
|
||
4. `docs/superpowers/reports/` 下的第二轮整改报告
|
||
|
||
## Completion Criteria
|
||
|
||
本计划完成的标志是：
|
||
|
||
1. `G2` 主样本达到候选验证门槛
|
||
2. `G2` 家族 blocker 从“稳定复现”转为“部分修复且可解释”
|
||
3. 后续是否切换到 `G1/G3`，可以建立在整改后二轮报告上，而不是继续依赖第一轮失败画像
|