claw/docs/superpowers/specs/2026-04-08-95598-repair-city-dispatch-operation-analysis.md

# 95598-repair-city-dispatch 操作分析

## 1. 场景概述

`95598-repair-city-dispatch` 对应“95598抢修-市指”场景，目标是监测抢修工单队列，并在必要时触发提醒、日志写入与自动派单等后续动作。根据 `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\scenes\95598-repair-city-dispatch\scene.json`、`D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\95598-repair-city-dispatch\SKILL.md`、`D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\95598-repair-city-dispatch\scripts\collect_repair_orders.js` 以及两份规则资产，当前最严谨的结论是：本场景的 packaged JS collector 已经实现输入驱动的 `monitor-snapshot` 归一化 / 比较逻辑，会按状态分桶 repair orders、解析 monitor/dispose logs、推导 `pending_ids` / `new_pending_ids`、给出 `success/partial/empty/blocked` 状态，并附带 desk 规则来源、配置基础页与已知问题元数据；但更强的业务监测、提醒与自动派单 workflow 证据仍主要存在于 desk 规则资产中，证据等级分别为 `code-confirmed`。

必须显式区分三层证据：

1. packaged runtime-snapshot-collector：`collect_repair_orders.js` 已直接实现 repair-order 分类、历史比较、状态判定与标准化快照输出，并显式携带 `workflow_rule_sources`、`config_base_page`、`config_base_role`、`packaged_collector_role` 与 `known_issues`，证据等级：`code-confirmed`。
2. 业务监测逻辑：`D:\desk\智能体资料\大四区报告监测项\95598抢修-市指_业务检测配置.txt` 直接展示了队列采集、状态分类、监测日志比较、音频提醒与监测日志写入逻辑，证据等级：`code-confirmed`。
3. 自动派单 / 提醒逻辑：`D:\desk\智能体资料\大四区报告监测项\95598抢修-市指_自动处理配置.txt` 直接展示了去重、班组匹配、自动派单请求、音频提醒、短信发送、外呼触发与处置日志写入逻辑，证据等级：`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\95598-repair-city-dispatch\scripts\collect_repair_orders.js`
   - 直接定义 `STATUS_GROUPS`、`LOCAL_SERVICE_ENDPOINTS`、`WORKFLOW_RULE_SOURCES`、`CONFIG_BASE_PAGE`、`KNOWN_ISSUES`，并实现 repair-order 分类、monitor/dispose log 解析比较、`new_pending_ids` 推导、`success/partial/empty/blocked` 状态判定，以及带 `evidence` / `known_issues` 的 `monitor-snapshot` 输出，证据等级：`code-confirmed`。
2. `D:\desk\智能体资料\大四区报告监测项\95598抢修-市指_业务检测配置.txt`
   - 直接实现工单队列采集、按状态分桶、待处理列表比较、音频提醒、监测日志写入，且暴露待处理分类 bug，证据等级：`code-confirmed`。
3. `D:\desk\智能体资料\大四区报告监测项\95598抢修-市指_自动处理配置.txt`
   - 直接实现处置日志去重、班组范围匹配、自动派单请求、自动派单成功/失败/异常/未匹配分支、音频日志、短信日志、外呼触发与 `setDisposeLog` 写入，证据等级：`code-confirmed`。
4. `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\95598-repair-city-dispatch\SKILL.md`
   - 定义“优先使用 packaged collector、把监测快照与下游动作分离、允许 partial”的运行契约，证据等级：`contract-defined`。
5. `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\95598-repair-city-dispatch\references\collection-flow.md`
   - 定义以页面配置为入口、结合规则资产理解语义、采集状态 `00/01/06/08`、对比 monitor/dispose logs 的一阶流程，证据等级：`contract-defined`。
6. `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\95598-repair-city-dispatch\references\data-quality.md`
   - 定义状态分类、partial 规则、empty/failure 区分和下游副作用边界，证据等级：`contract-defined`。
7. `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\scenes\95598-repair-city-dispatch\scene.json`
   - 声明场景分类、输入 `time`、依赖和动作类型，证据等级：`code-confirmed`。
8. `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\scenes\95598-repair-city-dispatch\scene.draft.json`
   - 展示早期推断中对 `trigger-alert`、`configServices` 是否拆分的犹豫，属于候选整理结果，证据等级：`no direct evidence / candidate only`。

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

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

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

运行边界方面，需要做两个强制区分：

- packaged JS runtime collector 的实际边界：它已经能基于输入 `repair_orders`、`monitor_logs`、`dispose_logs` 做状态分类、历史比较、`new_pending_ids` 推导与 `success/partial/empty/blocked` 判定，并返回标准 `monitor-snapshot`；但它仍是输入驱动归一化 collector，不直接发起浏览器请求，也不直接承载完整业务 workflow，证据等级：`code-confirmed`。
- rule-asset 行为边界：业务检测规则和自动处理规则分别展示了浏览器请求、日志比较、提醒副作用与自动派单副作用，证据等级：`code-confirmed`。

也就是说，本场景不能被单句描述成“统一 packaged collector 已完整实现实时队列监测与自动派单”。更严谨的说法是：packaged collector 已实现可测试的输入驱动快照归一化 / 比较逻辑；而较强的实时监测与自动处理链路证据仍来自 desk 规则资产，证据等级：`code-confirmed`。

同时，`SKILL.md` 与 reference 明确要求把“快照采集成功”与“音频、短信、外呼、自动派单等下游效果”分开表达；这属于运行契约约束，证据等级：`contract-defined`。

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

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

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

1. 调用 `collectRepairOrders(input)`，读取 `input.repair_orders`、`input.monitor_logs || input.monitor_log`、`input.dispose_logs || input.dispose_log`、`input.local_write_failures`、`input.blocked_reason` 等输入。
2. 通过 `classifyRepairOrders(...)` 按 `STATUS_GROUPS.pending = ["00", "01"]`、`STATUS_GROUPS.audit = ["06"]`、`STATUS_GROUPS.processed = ["08"]` 对 repair orders 分桶，并记录未知状态。
3. 从 pending orders 提取 `pending_ids`，再解析 monitor/dispose logs，识别 malformed payload，并据此推导 `new_pending_ids`。
4. 按 `blocked > partial > empty > success` 的优先级计算 `status`，并把未知状态、日志缺失、日志解析失败、本地写失败等写入 `partial_reasons`。
5. 返回 `type: "monitor-snapshot"`、`scene: "95598-repair-city-dispatch"`、`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"`，以及 `known_issues`。
7. 模块额外导出 `STATUS_GROUPS`、`LOCAL_SERVICE_ENDPOINTS`、`WORKFLOW_RULE_SOURCES`、`CONFIG_BASE_PAGE`、`KNOWN_ISSUES`。

以上都属于 `code-confirmed`。

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

`95598抢修-市指_业务检测配置.txt` 中可直接确认：

1. 通过 `BrowserAction("sgBrowerserJsAjax2", ...)` 请求 `repairOrder/list`，查询条件包含 `statusName=00,01,06,08` 与当天时间窗，证据等级：`code-confirmed`。
2. 将返回列表按状态分到 `list`、`shlist`、`ycjList`，并构造 `pending/audit/processed` 与 `pendingList`，证据等级：`code-confirmed`。
3. 读取 `getMonitorLog`，并基于待处理列表对比决定是否播报音频提醒，证据等级：`code-confirmed`。
4. 将监测结果写入 `setMonitorData` 与 `setMonitorLog`，证据等级：`code-confirmed`。
5. 音频提醒结果会写入 `setAudioPlayLog` 成功/失败/异常三类状态，证据等级：`code-confirmed`。

但这里同时存在一个直接可见的 bug：待处理判断写成了 `item.status == "00" && item.status == "01"`，这在单个状态值上不可能同时成立，因此规则中的 `pending` 列表构造逻辑不严谨，证据等级：`implementation intent exists but not rigorous / buggy`。

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

`95598抢修-市指_自动处理配置.txt` 中可直接确认：

1. 先写一条“进入自动派单”的监测日志，再读取 `getDisposeLog` 做已派单去重，证据等级：`code-confirmed`。
2. 对未派过单的待处理工单，读取 `getClassList`，按 `scope` 对故障地点 `gzdd` 做班组匹配，证据等级：`code-confirmed`。
3. 匹配成功时，请求 `repairOrder/initProcess` 进行自动派单，证据等级：`code-confirmed`。
4. 自动派单成功时，会触发成功音频播报、短信发送、外呼触发，并写 `setDisposeLog(state="成功")`，证据等级：`code-confirmed`。
5. 自动派单失败时，会触发失败音频播报，并写 `setDisposeLog(state="失败")`，证据等级：`code-confirmed`。
6. 自动派单异常时，会触发异常音频播报，并写 `setDisposeLog(state="异常")`，证据等级：`code-confirmed`。
7. 未匹配到班组时，会触发未匹配音频播报，并写 `setDisposeLog(state="未匹配")`，证据等级：`code-confirmed`。

以上动作都只是“规则层实现分支存在”的直接证据，不代表运行时已经验证成功。

## 5. 标准化抽象流程

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

1. 接收监测任务输入 `time`。
2. 使用规则资产定义的浏览器请求采集 95598 抢修队列。
3. 将源数据分为 `pending`、`audit`、`processed`，并保留规则层可见的待处理列表语义。
4. 用 monitor log / dispose log 做比较上下文，得出“新增待处理”或待自动处理集合。
5. 若进入标准配置归一层，再把这些结果映射为 `pending_ids`、`new_pending_ids` 等 canonical 字段。
6. 先返回或保留监测快照语义。
7. 再执行音频提醒、短信、外呼、自动派单、日志写入等下游动作。

其中第 1 步可由 packaged collector 的显式输入 `time` 支撑，第 3、4、5、6 步可由 packaged collector 的输入驱动归一化 / 比较逻辑支撑，证据等级：`code-confirmed`；第 2、7 步主要由规则资产直接支撑，证据等级：`code-confirmed`；“快照应先于下游副作用表达”这一边界来自 `SKILL.md` / references，证据等级：`contract-defined`。

如果进一步把这个抽象流程说成“已由统一 packaged collector 严格承载实时浏览器采集与自动派单副作用”，那就不严谨了，因为这些更强 workflow 证据仍在 desk 规则资产而不是 packaged collector 中，证据等级只能降为 `implementation intent exists but not rigorous / buggy`。

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

### 输入

- `time` 是 scene 与 packaged script 共同声明的显式输入，证据等级：`code-confirmed`。
- 当天时间窗拼接逻辑出现在业务监测规则中，即 `00:00:00` 到 `23:59:59`，证据等级：`code-confirmed`。
- “当前队列窗口通常是当天”在 reference 中被明确说明，证据等级：`contract-defined`。

### 运行上下文

- 平台 session、org/user 上下文、浏览器可执行 `BrowserAction` 是规则资产和 reference 共同依赖的前提，证据等级分别为 `code-confirmed` 与 `contract-defined`。
- 页面本身更偏配置页，而真正监测语义来自规则资产，这一点在 `collection-flow.md` 中被明确指出，证据等级：`contract-defined`。

### 依赖

- `scene.json` 中声明 `browser`、`local-service`、`repair-order-source`、`history-log`、`status-classification`，证据等级：`code-confirmed`。
- 业务监测规则直接使用 `repairOrder/list`、`MonitorServices/getMonitorLog`、`setMonitorData`、`setMonitorLog`、`setAudioPlayLog`，证据等级：`code-confirmed`。
- 自动处理规则直接使用 `getDisposeLog`、`getClassList`、`repairOrder/initProcess`、`setDisposeLog`、`setSendMessageLog` 与外呼触发 `mac.callOutLogin`，证据等级：`code-confirmed`。
- `configServices` 是否需要单独提升为正式依赖，在 `scene.draft.json` 中仍是待确认项，证据等级：`no direct evidence / candidate only`。

## 7. 输出结构

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

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

`collect_repair_orders.js` 直接定义：

- `type: "monitor-snapshot"`
- `scene: "95598-repair-city-dispatch"`
- `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`
- `known_issues`

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

### 7.2 规则资产已展示的实际快照字段语义

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

- `time`
- `type: "95598抢修-市指"`
- `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 log / dispose log 做比较并决定是否提醒或进入自动派单”，而没有看到显式字段 `new_pending_ids` 被直接写出，因此“存在历史比较意图”是 `code-confirmed`，“`new_pending_ids` 已被当前实现严谨产出”只能标为 `implementation intent exists but not rigorous / buggy`。

## 8. 下游动作证据表

| 下游动作 | 当前证据 | 证据等级 | 严谨结论 |
| --- | --- | --- | --- |
| 返回 `monitor-snapshot` runtime collector 输出 | `collect_repair_orders.js` 直接返回对象 | `code-confirmed` | packaged JS 直接证明标准 snapshot 字段、状态判定与 collector metadata 已存在。 |
| 队列采集请求 | 业务监测规则调用 `repairOrder/list` | `code-confirmed` | 队列采集逻辑直接存在于规则资产中。 |
| 音频提醒调用 | 业务监测规则和自动处理规则都调用 `mac.audioPlay(...)` | `code-confirmed` | 只能确认规则层存在音频提醒调用，不代表运行时已验证成功。 |
| 短信发送调用 | 自动处理规则调用 `mac.sendMessages(request)` | `code-confirmed` | 只能确认规则层存在短信发送调用。 |
| 电话 / 外呼触发 | 自动处理规则调用 `mac.callOutLogin(params)` | `code-confirmed` | 只能确认规则层存在外呼触发分支。 |
| 自动派单请求调用 | 自动处理规则请求 `repairOrder/initProcess` | `code-confirmed` | 自动派单请求分支可直接定位。 |
| `setDisposeLog` 成功写入 | 自动处理规则成功分支写 `state="成功"` | `code-confirmed` | 成功路径处置日志写入定义明确存在。 |
| `setDisposeLog` 失败写入 | 自动处理规则失败分支写 `state="失败"` | `code-confirmed` | 失败路径处置日志写入定义明确存在。 |
| `setDisposeLog` 异常写入 | 自动处理规则异常分支写 `state="异常"` | `code-confirmed` | 异常路径处置日志写入定义明确存在。 |
| `setDisposeLog` 未匹配写入 | 自动处理规则未匹配分支写 `state="未匹配"` | `code-confirmed` | 未匹配路径处置日志写入定义明确存在。 |
| `new_pending_ids` 严格产出 | 只在 skill/reference/data-quality 中被要求 | `implementation intent exists but not rigorous / buggy` | 有明确目标语义，但当前读到的规则资产未直接产出同名字段。 |
| 把下游动作结果等同于采集成功 | skill/reference 明确禁止 | `contract-defined` | 契约要求把快照成功与副作用成功分离。 |

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

1. 最明显的已知 bug 是业务监测规则中的待处理分类条件写成 `item.status == "00" && item.status == "01"`。这会导致 `pending` 分桶逻辑不可能按作者意图工作，证据等级：`implementation intent exists but not rigorous / buggy`。
2. packaged collector 与规则资产的输出命名仍不一致：collector 使用 `scene`、`pending_ids`、`new_pending_ids`，规则对象使用 `type`、`pendingList`，证据等级：`code-confirmed`。
3. `SKILL.md` 把 `new_pending_ids` 作为输出重点，但当前直接证据更强的是“做日志比较并决定提醒/自动派单”，而不是“显式产出同名字段”，证据等级：`implementation intent exists but not rigorous / buggy`。
4. `scene.draft.json` 仍在犹豫 `trigger-alert` 是否拆成 audio-alert、message-alert、callout 三类动作，说明标准动作建模尚未完全收敛，证据等级：`no direct evidence / candidate only`。
5. 虽然规则层存在音频、短信、外呼、自动派单与日志写入定义，但本文不能据此声称这些动作已完成运行时验证，任何这种拔高都不严谨。

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

1. 对本场景应显式拆分两层实现证据：
   - `packaged_collector`: `collect_repair_orders.js` 的 runtime snapshot collector、状态判定、历史比较与 metadata（规则来源、配置基础页角色、已知问题），证据等级：`code-confirmed`；
   - `rule_asset_workflow`: 业务监测与自动处理规则资产中的真实流程分支，证据等级：`code-confirmed`。
2. 在标准配置中把业务监测与自动处理拆成两个子流程：
   - `monitoring_flow` 对应 `95598抢修-市指_业务检测配置.txt`；
   - `auto_processing_flow` 对应 `95598抢修-市指_自动处理配置.txt`。
   这样可以避免把两份规则混成单一 collector。
3. 输出 schema 建议区分：
   - `canonical_snapshot_fields`: `pending_ids` / `new_pending_ids` 等标准字段；
   - `observed_rule_fields`: `pendingList` / `type` 等规则层字段。
   当前两套命名并存，证据等级：`code-confirmed`。
4. 对状态分类增加 `known_bug_note`，明确记录 `status == "00" && status == "01"` 的待处理分类 bug，防止后续文档误把 pending 计数写成稳定事实，证据等级：`implementation intent exists but not rigorous / buggy`。
5. 对下游动作增加 `effect_channels` 明细，至少拆出 `audio-reminder`、`sms-send`、`callout-trigger`、`auto-dispatch-request`、`dispose-log-write`，因为这些都已在规则资产中直接出现，证据等级：`code-confirmed`。

## 11. 最终严谨结论

关于 `95598-repair-city-dispatch`，当前最可靠的结论是：仓库已经同时存在一个可测试的 packaged JS runtime collector，以及两份更强的 desk 规则脚本实现（`D:\desk\智能体资料\大四区报告监测项\95598抢修-市指_业务检测配置.txt`、`D:\desk\智能体资料\大四区报告监测项\95598抢修-市指_自动处理配置.txt`），其中 packaged collector 已直接实现 repair-order 分类、monitor/dispose log 比较、`new_pending_ids` 推导与 `success/partial/empty/blocked` 状态判定；业务监测规则直接证实了队列采集、日志比较、音频提醒与监测日志写入，自动处理规则直接证实了去重、班组匹配、自动派单请求、短信发送、外呼触发以及 `setDisposeLog` 在成功 / 失败 / 异常 / 未匹配路径上的写入定义，证据等级：`code-confirmed`。

但同样必须严格说明：这些 `code-confirmed` 只证明“代码或规则层存在这些实现分支”，不证明运行时已验证成功。此外，desk 业务监测规则里还存在 `status == "00" && status == "01"` 的待处理分类 bug，因此 rule workflow 本身也不能被描述为严谨无误。对 command-center 而言，本场景最应该被建模为“packaged collector 已具备输入驱动快照归一化能力、desk rule-asset workflow 证据更强、且监测流与自动处理流必须分开表达”的 monitor scene。