# jiayuguan-meter-outage 操作分析

## 1. 场景概述

`jiayuguan-meter-outage` 对应“户表失电-嘉峪关”场景，目标是采集户表失电事件、关联服务工单状态、对比历史监测 / 处置日志，并在必要时触发音频提醒或自动派单等后续动作。根据 `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\scenes\jiayuguan-meter-outage\scene.json`、`D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\jiayuguan-meter-outage\SKILL.md`、`D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\jiayuguan-meter-outage\scripts\collect_outage_events.js` 以及两份规则资产，当前最严谨的结论是：packaged JS collector 已经实现输入驱动的 `monitor-snapshot` 归一化 / 比较逻辑，会从 outage events 与 service orders 计算 `pending/audit/processed`、解析 monitor/dispose logs、推导 `pending_ids` / `new_pending_ids`、输出 `success/partial/empty/blocked` 状态，并附带 source endpoint 常量、localhost 端点、desk 规则来源、配置基础页标记与身份模型元数据；更强的业务工作流证据则主要存在于 desk 规则资产中，证据等级分别为 `code-confirmed`。

必须明确区分以下几层：

1. packaged runtime-snapshot-collector：`collect_outage_events.js` 已直接实现 outage/service-order 归一化、历史比较、身份模型暴露与标准快照输出，并显式携带 `workflow_rule_sources`、`config_base_page`、`config_base_role`、`packaged_collector_role` 与 `identity_model` 元数据，证据等级：`code-confirmed`。
2. outage collection：业务监测规则直接请求 `outage/dhsd/dhsdList` 收集失电事件，证据等级：`code-confirmed`。
3. service-order enrichment：业务监测规则再请求 `gdgl/active/service/order/list` 收集服务工单状态并补全 `audit` / `processed`，证据等级：`code-confirmed`。
4. monitor-log comparison：业务监测规则通过 `getMonitorLog` 对比历史待处理列表并决定是否音频提醒，证据等级：`code-confirmed`。
5. dispose-log dedupe：业务监测规则通过 `getDisposeLog` 做已派单去重并决定是否进入自动处理，证据等级：`code-confirmed`。
6. marketing-token-dependent auto-processing and dispatch：自动处理规则显式读取营销系统 token，并基于营销系统查询结果、班组配置和自动派单接口推进派单，证据等级：`code-confirmed`。

但这些 `code-confirmed` 仍只证明“代码或规则资产中存在这些实现链路”，不代表运行时已验证成功。本文不声称任何运行时验证结论。

## 2. 证据来源

本分析统一只使用四个证据等级标签：`code-confirmed`、`contract-defined`、`implementation intent exists but not rigorous / buggy`、`no direct evidence / candidate only`。

1. `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\jiayuguan-meter-outage\scripts\collect_outage_events.js`
   - 直接定义 `SOURCE_GROUPS`、`LOCAL_SERVICE_ENDPOINTS`、`WORKFLOW_RULE_SOURCES`、`CONFIG_BASE_PAGE`、`IDENTITY_MODEL`，并实现 outage/service-order 分类、monitor/dispose log 解析比较、`new_pending_ids` 推导、`success/partial/empty/blocked` 状态判定，以及带 `evidence` / `identity_model` 的 `monitor-snapshot` 输出，证据等级：`code-confirmed`。
2. `D:\desk\智能体资料\大四区报告监测项\户表失电-嘉峪关_业务监测配置.txt`
   - 直接实现失电事件采集、服务工单状态补充、monitor log 比较、dispose log 去重、音频提醒与监测日志写入，证据等级：`code-confirmed`。
3. `D:\desk\智能体资料\大四区报告监测项\户表失电-嘉峪关_自动处理配置.txt`
   - 直接实现营销 token 读取、营销系统用户查询、工单编号获取、班组分配、自动派单请求、音频提醒、处置日志写入，以及备用短信函数定义，证据等级：`code-confirmed`。
4. `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\jiayuguan-meter-outage\SKILL.md`
   - 定义“失电事件采集与工单状态采集要分开，再组合成一份快照；下游提醒与自动派单不应重定义采集成功”的运行契约，证据等级：`contract-defined`。
5. `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\jiayuguan-meter-outage\references\collection-flow.md`
   - 定义以配置页为入口、组合 outage-event collection、service-order enrichment、历史比较和 auto-processing context 的流程，证据等级：`contract-defined`。
6. `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\jiayuguan-meter-outage\references\data-quality.md`
   - 定义 pending / audit / processed 的来源语义、partial 规则与依赖告警，证据等级：`contract-defined`。
7. `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\scenes\jiayuguan-meter-outage\scene.json`
   - 声明场景分类、输入 `time`、依赖与动作，证据等级：`code-confirmed`。
8. `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\scenes\jiayuguan-meter-outage\scene.draft.json`
   - 暴露对 marketing token context 和 `trigger-alert` / `auto-processing` 是否进一步拆分的待定整理，证据等级：`no direct evidence / candidate only`。

## 3. 实际入口与运行边界

实际入口在 `scene.json` 中已固定：场景页面入口为 `index.html`，技能工具名为 `jiayuguan-meter-outage.collect_outage_events`，输出类型为 `monitor-snapshot`，输入为 `time`，这些都属于 `code-confirmed`。

其中 `assets/scene-snapshot/index.html` 只应被视为配置基础页（例如班组、联系人、范围维护），不应被当作规则 workflow 的主执行证据。

运行边界方面，需要特别强调 packaged collector 与 rule workflow 的分层：

- packaged JS runtime collector 的直接能力边界：它已经能基于输入 `outage_events`、`service_orders`、`monitor_logs`、`dispose_logs` 做 `pending/audit/processed` 归一化、历史比较、`new_pending_ids` 推导与 `success/partial/empty/blocked` 判定，并公开两个上游 source endpoint、一组 localhost endpoint、desk 规则来源、配置基础页角色与身份模型元数据；但它仍是输入驱动归一化 collector，不直接发起浏览器请求，也不直接承载完整业务 workflow，证据等级：`code-confirmed`。
- 更强的业务流程边界，主要体现在 desk 规则资产：先采集户表失电事件，再请求服务工单列表补充状态，再做 monitor/dispose 日志比较，最后才决定提醒或自动处理，证据等级：`code-confirmed`。

因此，本场景不能被描述成“packaged collector 已完整实现嘉峪关户表失电实时工作流”。更严谨的说法是：packaged collector 已实现可测试的输入驱动快照归一化 / 比较逻辑；较强 workflow 证据主要在 desk 规则资产中，证据等级：`code-confirmed`。

此外，`collection-flow.md` 与 `SKILL.md` 都明确要求把 outage collection、service-order enrichment、历史比较与下游 auto-processing 分开理解；这是运行边界契约，证据等级：`contract-defined`。

## 4. 代码已证实的实际操作流程

### 4.1 packaged runtime-snapshot-collector 已证实流程

`collect_outage_events.js` 中现在能严格确认：

1. 调用 `collectOutageEvents(input)`，读取 `input.outage_events`、`input.service_orders`、`input.monitor_logs || input.monitor_log`、`input.dispose_logs || input.dispose_log`、`input.local_write_failures`、`input.blocked_reason` 等输入。
2. 通过 `buildOutageContext(...)` 从 outage events 提取 `pending_ids`、`eventIds` 与 `eventIdsByConsNo`，并通过 `classifyServiceOrders(...)` 基于 `gdztmc` 计算 `audit` / `processed`。
3. 解析 monitor/dispose logs，识别 malformed payload，并结合 `consNo` 与 `eventId` 的映射推导 `new_pending_ids`。
4. 对未知工单状态、日志缺失、日志解析失败、缺失 event identity、identity crosswalk ambiguity、本地写失败等情况记录 `partial_reasons`。
5. 按 `blocked > partial > empty > success` 的优先级计算 `status`，返回 `type: "monitor-snapshot"`、`scene: "jiayuguan-meter-outage"`、`pending`、`audit`、`processed`、`pending_ids`、`new_pending_ids`、`status`、`partial_reasons`。
6. 在返回对象中附带 `evidence.workflow_rule_sources`、`evidence.config_base_page`、`evidence.config_base_role`、`evidence.packaged_collector_role = "runtime-snapshot-collector"`，以及 `identity_model`。
7. 模块额外导出 `SOURCE_GROUPS`、`LOCAL_SERVICE_ENDPOINTS`、`WORKFLOW_RULE_SOURCES`、`CONFIG_BASE_PAGE`、`IDENTITY_MODEL`。

以上都属于 `code-confirmed`。

### 4.2 业务监测规则已证实流程

`户表失电-嘉峪关_业务监测配置.txt` 直接证实了以下分段流程：

1. outage collection：通过 `BrowserAction(... outage/dhsd/dhsdList ...)` 查询近两天到当天的失电事件，并把每条 `consNo` 放入 `idList`，证据等级：`code-confirmed`。
2. service-order enrichment：随后通过 `BrowserAction(... gdgl/active/service/order/list ...)` 查询当天工单列表，并按 `gdztmc == "待审核"` / `gdztmc == "已归档"` 分别累计 `audit` 与 `processed`，证据等级：`code-confirmed`。
3. monitor-log comparison：通过 `getMonitorLog` 读取历史 `pendingList`，对比当前 `idList`，如发现新增待处理则触发音频提醒，并把快照写入 `setMonitorData` / `setMonitorLog`，证据等级：`code-confirmed`。
4. dispose-log dedupe：通过 `getDisposeLog` 读取历史处置日志，解析 `orderID` 后提取其中 `id`，再以 `eventId` 为键从当前失电事件中筛出未处置事件 `pendingList`，证据等级：`code-confirmed`。
5. 若存在未处置事件，则把 `pendingList` 塞给 `_this.queueObj.pendingList` 并触发 `_this.autoTask()`；否则直接 `_this.processQueue()`，证据等级：`code-confirmed`。

### 4.3 自动处理规则已证实流程

`户表失电-嘉峪关_自动处理配置.txt` 直接证实：

1. 自动处理依赖营销系统 token：代码从 `localStorage["markYXObj"]` 中读取 `token` 与 `loginUserInfo`，证据等级：`code-confirmed`。
2. 自动处理先按 `eqPsrName` 合并事件，再读取 `getClassList` 获取班组配置，证据等级：`code-confirmed`。
3. 用营销系统接口 `queryEleCust` 按 `consNo` 查询用户营销归属，再据此确定 `ecssMgtOrgCode`，证据等级：`code-confirmed`。
4. 之后还会调用 `gdgl/zdfw/tgforderzdfw/gdbh` 获取工单编号，再调用 `gdgl/active/service/order/saveAndSend` 发起自动派单，证据等级：`code-confirmed`。
5. 自动派单成功 / 失败 / 异常分支都会触发不同音频提醒，并写 `setDisposeLog`，证据等级：`code-confirmed`。
6. 短信函数 `msgFC` 在自动处理规则中被定义，但当前成功分支里的短信发送代码被整体注释掉，因此“短信通道已成为当前有效工作流”不能被写成稳定事实，证据等级：`implementation intent exists but not rigorous / buggy`。

## 5. 标准化抽象流程

若为 command-center 做严格抽象，本场景更合理的标准化流程应写成：

1. 接收监测任务输入 `time`。
2. 单独采集 outage events。
3. 单独采集 service-order states，并用其补充 `audit` / `processed`。
4. 使用 monitor log 做待处理比较，判断提醒语义。
5. 使用 dispose log 做已处置去重，筛出需要自动处理的事件集合。
6. 先形成或保留监测快照语义。
7. 若满足条件，再进入依赖营销 token 的自动处理 / 派单流程。
8. 记录音频、日志与处置结果等下游动作。

其中第 1 步可由 packaged collector 的显式输入 `time` 支撑，第 2、3、4、5、6 步可由 packaged collector 的输入驱动归一化 / 比较逻辑支撑，证据等级：`code-confirmed`；第 7、8 步主要由规则资产直接支撑，证据等级：`code-confirmed`；“这些步骤应被分离理解、下游动作不应覆盖采集成功语义”的边界来自 `SKILL.md` / references，证据等级：`contract-defined`。

如果把上述流程进一步说成“已由 packaged collector 严格统一承载实时 outage 请求、service-order 查询与自动派单副作用”，则不严谨，因为这些更强 workflow 证据主要来自 desk 规则资产而不是 packaged collector，证据等级只能降为 `implementation intent exists but not rigorous / buggy`。

## 6. 输入、上下文与依赖

### 输入

- `time` 是 scene 与 packaged script 共同声明的显式输入，证据等级：`code-confirmed`。
- 业务监测规则对失电事件使用“近两天到今天”的 `offTime` 查询窗，对服务工单使用“当天”的 `createTime` 查询窗，证据等级：`code-confirmed`。
- “当前 outage 和 service-order query windows 都属于实际输入的一部分”在 reference 中被明确说明，证据等级：`contract-defined`。

### 运行上下文

- 平台 session、org/user 上下文、浏览器 `BrowserAction` 能力在规则资产中直接使用，证据等级：`code-confirmed`。
- marketing token context 在自动处理规则中是实际依赖，而不仅仅是文档说法，证据等级：`code-confirmed`。
- reference 也把 marketing token context 明确列为 downstream enrichment / dispatch 依赖，证据等级：`contract-defined`。

### 依赖

- `scene.json` 声明 `browser`、`local-service`、`outage-source`、`service-order-source`、`history-log`，证据等级：`code-confirmed`。
- 业务监测规则直接使用 `outage/dhsd/dhsdList`、`gdgl/active/service/order/list`、`getMonitorLog`、`setMonitorData`、`setMonitorLog`、`getDisposeLog`、`setAudioPlayLog`，证据等级：`code-confirmed`。
- 自动处理规则直接使用营销系统 `queryEleCust`、工单编号接口 `gdgl/zdfw/tgforderzdfw/gdbh`、自动派单接口 `gdgl/active/service/order/saveAndSend`、`setDisposeLog` 与 `setAudioPlayLog`，证据等级：`code-confirmed`。
- `scene.draft.json` 中 marketing token context 是否应提升为正式 dependency 仍是待确认项，因此在标准配置整理上属于 `no direct evidence / candidate only`。

## 7. 输出结构

当前输出结构需要分层描述。

### 7.1 packaged runtime collector 已直接定义的输出

`collect_outage_events.js` 直接定义：

- `type: "monitor-snapshot"`
- `scene: "jiayuguan-meter-outage"`
- `time`
- `pending`
- `audit`
- `processed`
- `pending_ids`
- `new_pending_ids`
- `status`
- `partial_reasons`
- `evidence.workflow_rule_sources`
- `evidence.config_base_page`
- `evidence.config_base_role`
- `evidence.packaged_collector_role`
- `identity_model`

以上全部属于 `code-confirmed`。

### 7.2 业务监测规则已展示的实际快照字段语义

业务监测规则直接构造了：

- `time`
- `type: "户表失电-嘉峪关"`
- `pending`
- `pendingList`
- `audit`
- `processed`

这说明规则层快照对象与 packaged stub 的标准字段命名并不完全一致，尤其是 `pendingList` vs `pending_ids`、`type` vs `scene`，证据等级：`code-confirmed`。

### 7.3 `new_pending_ids` 的证据强度与身份不一致问题

`SKILL.md`、reference 与 `data-quality.md` 把 `new_pending_ids` 当成目标输出的一部分，证据等级：`contract-defined`。但当前规则资产里更强的直接事实是：

- monitor pending list 使用的是 `consNo`，即 `idList.push(item.consNo)`，证据等级：`code-confirmed`；
- dispose dedupe 使用的是 `eventId`，即比较 `resList.indexOf(y.eventId)`，证据等级：`code-confirmed`。

这意味着当前实现存在明显身份不一致：监测 pending 列表是 `consNo` 视角，而处置去重是 `eventId` 视角。因而“`pending_ids` / `new_pending_ids` 已被当前实现严谨统一定义”不能成立，证据等级：`implementation intent exists but not rigorous / buggy`。

## 8. 下游动作证据表

| 下游动作 | 当前证据 | 证据等级 | 严谨结论 |
| --- | --- | --- | --- |
| 返回 `monitor-snapshot` runtime collector 输出 | `collect_outage_events.js` 直接返回对象 | `code-confirmed` | packaged JS 直接证明标准 snapshot 字段、状态判定、身份说明与 collector metadata 已存在。 |
| 失电事件采集 | 业务监测规则调用 `outage/dhsd/dhsdList` | `code-confirmed` | outage collection 在规则资产中直接存在。 |
| 服务工单状态补充 | 业务监测规则调用 `service/order/list` 并按 `gdztmc` 分桶 | `code-confirmed` | service-order enrichment 直接存在。 |
| monitor-log 比较 | 业务监测规则调用 `getMonitorLog` 并对比 `consNo` 列表 | `code-confirmed` | 历史比较逻辑直接存在。 |
| dispose-log 去重 | 业务监测规则调用 `getDisposeLog` 并按 `eventId` 过滤 | `code-confirmed` | 去重逻辑直接存在，但身份键与 monitor pending list 不一致。 |
| 音频提醒调用 | 业务监测规则和自动处理规则都调用 `mac.audioPlay(...)` | `code-confirmed` | 只能确认规则层存在音频提醒调用。 |
| 自动派单请求 | 自动处理规则调用 `service/order/saveAndSend` | `code-confirmed` | 自动派单请求分支可直接定位。 |
| 依赖营销 token 的用户查询 | 自动处理规则调用营销系统 `queryEleCust`，请求头带 `auth_token` | `code-confirmed` | 自动处理对 marketing token 有明确硬依赖。 |
| `setDisposeLog` 成功 / 失败 / 异常写入 | 自动处理规则各分支都写 `setDisposeLog` | `code-confirmed` | 处置日志写入分支存在。 |
| 短信发送通道 | 自动处理规则定义 `msgFC`，但成功分支短信代码被注释 | `implementation intent exists but not rigorous / buggy` | 说明短信意图存在，但当前读取到的有效工作流未严格启用。 |
| `pending_ids` / `new_pending_ids` 严格统一 | skill/reference 有目标要求，但规则层 `consNo` 与 `eventId` 混用 | `implementation intent exists but not rigorous / buggy` | 当前身份模型不统一，不能写成严谨既成事实。 |

## 9. 当前代码疑点 / 不严谨点

1. 最关键的不严谨点是身份不一致：monitor pending list 以 `consNo` 作为待处理标识，而 dispose dedupe 以 `eventId` 作为去重标识。这会让 `pending_ids`、`new_pending_ids` 与“已处置集合”的语义难以严格对齐，证据等级：`implementation intent exists but not rigorous / buggy`。
2. packaged collector 与规则资产输出命名仍不一致：collector 使用 `scene`、`pending_ids`、`new_pending_ids`，规则对象使用 `type`、`pendingList`，证据等级：`code-confirmed`。
3. `SKILL.md` 明确要求把 outage collection 与 service-order enrichment 分离理解；当前规则确实这样做了，但 packaged stub 没有承载这层结构，因此如果 command-center 只读 packaged stub 会低估真实 workflow，证据等级：`code-confirmed`。
4. 自动处理强依赖 marketing token，但 `scene.json` 现有正式 dependencies 没把它显式列出；`scene.draft.json` 已把这点作为待确认项，说明标准依赖建模尚未闭合，证据等级：`implementation intent exists but not rigorous / buggy`。
5. 自动处理规则中短信发送函数虽然存在，但主成功路径短信代码被注释，说明短信通道更像保留意图而非当前可靠工作流，证据等级：`implementation intent exists but not rigorous / buggy`。
6. 本文不能根据规则中存在自动派单和音频分支，就声称这些分支已经过运行时验证；任何这种表述都应避免。

## 10. 对 command-center 标准配置的修订建议

1. 对本场景应显式拆分两层证据：
   - `packaged_collector`: `collect_outage_events.js` 的 runtime snapshot collector、状态判定、历史比较与 metadata（规则来源、配置基础页角色、身份模型），证据等级：`code-confirmed`；
   - `rule_asset_workflow`: 规则资产中的 outage collection、service-order enrichment、历史比较与自动处理流程，证据等级：`code-confirmed`。
2. 标准工作流建议强制拆成五段：
   - `outage_collection`
   - `service_order_enrichment`
   - `monitor_log_comparison`
   - `dispose_log_dedupe`
   - `marketing_token_dependent_auto_processing`
   这些拆分都能由现有规则资产直接支撑，证据等级：`code-confirmed`。
3. 标准配置中应单独增加 `identity_model_note`，明确当前监测 pending list 基于 `consNo`，而 dispose dedupe 基于 `eventId`，两者尚未统一，证据等级：`implementation intent exists but not rigorous / buggy`。
4. 对 dependencies 建议把 `marketing-token-context` 提升为显式依赖项，因为自动处理规则确实直接读取并使用营销 token，证据等级：`code-confirmed`；但“如何在标准 scene schema 中表达”目前仍是配置整理问题，证据等级：`implementation intent exists but not rigorous / buggy`。
5. 对输出 schema 建议区分：
   - `canonical_snapshot_fields`: `pending_ids` / `new_pending_ids` 等标准字段；
   - `observed_rule_fields`: `pendingList` / `type` 等规则字段。
   并额外记录 `pending_identity = consNo`、`dispose_identity = eventId` 的差异，避免误建模。

## 11. 最终严谨结论

关于 `jiayuguan-meter-outage`，当前最可靠的结论是：仓库已经存在一个可测试的 packaged JS runtime collector，以及两份更强的 desk 规则脚本实现（`D:\desk\智能体资料\大四区报告监测项\户表失电-嘉峪关_业务监测配置.txt`、`D:\desk\智能体资料\大四区报告监测项\户表失电-嘉峪关_自动处理配置.txt`）。其中 packaged collector 已直接实现 outage/service-order 归一化、monitor/dispose log 比较、`new_pending_ids` 推导与 `success/partial/empty/blocked` 状态判定；业务监测规则直接证实了 outage collection、service-order enrichment、monitor-log comparison、dispose-log dedupe 与音频提醒 / 监测日志写入；自动处理规则则直接证实了依赖 marketing token 的用户归属查询、工单编号获取、自动派单请求以及音频 / 处置日志副作用分支，证据等级：`code-confirmed`。

但同样必须严格说明：更强 workflow 证据主要在 desk 规则资产中，而不是 packaged collector；因此不能把本场景描述成“packaged collector 已严谨实现全部实时业务流程”。此外，当前实现仍存在关键身份不一致问题：monitor pending list 使用 `consNo`，dispose dedupe 使用 `eventId`。这说明本场景虽然 workflow 证据较强，但 `pending_ids` / `new_pending_ids` 的统一身份模型仍不严谨，最适合被描述为“packaged collector 已具备输入驱动快照归一化能力、desk rule-asset workflow 较强、且身份键需要在 command-center 标准配置中显式澄清”的 monitor scene。