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。