claw/docs/superpowers/specs/2026-04-08-command-center-virtual-employee-inventory-table.md

# 指挥中心虚拟员工业务盘点清单（表格版）

> 说明：本文件是“当前状态总览”，不是目标配置 schema。自本次重写起，所有判断统一采用 `code-confirmed`、`contract-defined`、`implementation intent exists but not rigorous / buggy`、`no direct evidence / candidate only` 四级证据模型；结论仅基于已暂存/已落库资产的静态检查结果，不代表任何运行时验证。

## 盘点范围

本表覆盖当前已整理的 5 个 staged scene / skill：

- `fault-details-report`
- `jinchang-business-environment-weekly-report`
- `95598-weekly-monitor-report`
- `95598-repair-city-dispatch`
- `jiayuguan-meter-outage`

## 虚拟员工定位

以下“虚拟员工定位”是对当前 5 个 scene 的归一化汇总视角，不是当前仓库里已存在统一员工对象的直接事实；证据等级：`no direct evidence / candidate only`。在这个归一化视角下，可把它理解为“面向电力业务指挥中心的任务型虚拟运营员工”，其职责边界可概括为：

- 以报表模板或监测快照形式承载结构化结果
- 对工单/事件队列做规则化监测与历史比较
- 为提醒、日志、外呼、自动派单、自动处理等下游动作提供输入语义
- 为未来统一配置清单提供归一化抽象基础

但必须强调：以上职责并不等于所有场景都已由统一 packaged runtime 严格实现，更不等于已完成运行时验证。

## 证据标签速记

| 标签 | 严格含义 |
| --- | --- |
| `code-confirmed` | 当前仓库代码、规则资产、静态配置中可直接定位到的事实 |
| `contract-defined` | 由场景说明、参考流程、接口/文档契约明确规定的事实 |
| `implementation intent exists but not rigorous / buggy` | 已看到实现方向或局部链路，但不够严谨、存在缺口或已知 bug |
| `no direct evidence / candidate only` | 当前没有直接证据，只能作为候选抽象、候选结构或待确认项 |

## 业务盘点表

| 名称 | 场景 ID | 类别 | 当前任务目标 | 已观察系统 / 证据基础 | 证据分级摘要 | 严格说明 / 未解决问题 | 对应分析文档 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 故障明细 | `fault-details-report` | 报表 | 以“故障明细主表 + summary-sheet 分区”形式承载故障明细报表结果。 | `scene.json`、`SKILL.md`、`scripts/collect_fault_details.js`、`references/collection-flow.md`、`references/data-quality.md` | `code-confirmed`：已直接定义 `report-artifact` 外壳、主表列、`summary-sheet` 模板、`status`/`partial_reasons` 字段。`contract-defined`：页面时间读取、故障查询、字段归一、汇总派生、导出/日志语义。`implementation intent exists but not rigorous / buggy`：`period` 与 `startTime/endTime` 建模不严谨，状态细分只停留在契约层。 | 当前更像“报表 schema/template stub”，不能写成已严格实现实时浏览器采集器；不得表述为已运行验证。 | `D:/data/ideaSpace/rust/sgClaw/claw-new/docs/superpowers/specs/2026-04-08-fault-details-report-operation-analysis.md` |
| 国网金昌供电公司营商环境周例会报告 | `jinchang-business-environment-weekly-report` | 报表 | 以四个固定 section 模板承载营商环境周报。 | `scene.json`、`SKILL.md`、`scripts/collect_business_environment_metrics.js`、`references/collection-flow.md`、`references/data-quality.md` | `code-confirmed`：四个 section template、空 artifact、`period`、基础状态字段已存在。`contract-defined`：多来源指标采集、周范围读取、section 聚合、导出/日志语义。`implementation intent exists but not rigorous / buggy`：`region` 仅在文案层出现，未进入稳定 schema。 | 这是“分区化周报模板”而不是已证实的 live collector；不能写成已稳定采集多个业务系统。 | `D:/data/ideaSpace/rust/sgClaw/claw-new/docs/superpowers/specs/2026-04-08-jinchang-business-environment-weekly-report-operation-analysis.md` |
| 95598、12398及配网设备监控情况周统计 | `95598-weekly-monitor-report` | 报表 | 以六个固定 section 模板承载周统计结果。 | `scene.json`、`SKILL.md`、`scripts/collect_weekly_metrics.js`、`references/collection-flow.md`、`references/data-quality.md` | `code-confirmed`：六个 section template、空 artifact、顶层 `period`、基础状态字段已存在。`contract-defined`：双周期输入、period alignment、多来源周统计采集。`implementation intent exists but not rigorous / buggy`：`period` vs `currentPeriod/cumulativePeriod` 冲突明显，period alignment 只在元数据/文档层被要求。 | 三个报表 scene 都更接近“已打包的 schema/template stub”，不应写成已实现 live collector；本场景还存在双周期建模未闭合问题。 | `D:/data/ideaSpace/rust/sgClaw/claw-new/docs/superpowers/specs/2026-04-08-95598-weekly-monitor-report-operation-analysis.md` |
| 95598抢修-市指 | `95598-repair-city-dispatch` | 监测 | 监测抢修工单队列，识别待处理/审核/已处理，并为提醒、日志、自动派单等链路提供输入。 | `scene.json`、`SKILL.md`、`scripts/collect_repair_orders.js`、`D:/desk/智能体资料/大四区报告监测项/95598抢修-市指_业务检测配置.txt`、`D:/desk/智能体资料/大四区报告监测项/95598抢修-市指_自动处理配置.txt` | `code-confirmed`：packaged JS 现已直接实现输入驱动的 `monitor-snapshot` collector，可做 repair-order 分类、monitor/dispose log 比较、`new_pending_ids` 推导、`success/partial/empty/blocked` 状态判定，并携带 `workflow_rule_sources`、`config_base_page/config_base_role`、`known_issues` 元数据；更强的队列采集、日志比较、音频提醒、短信、外呼、自动派单、处置日志写入证据直接存在于 desk 规则脚本。`contract-defined`：快照语义与下游副作用需分开表达。`implementation intent exists but not rigorous / buggy`：desk 规则内存在 `status == "00" && status == "01"` 的待处理分类 bug；规则层 `new_pending_ids` 仍更像归一化目标而非同名稳定字段。 | 本场景 desk workflow 证据仍强于 packaged collector，且当前实际定时执行证据以 desk 规则脚本为主；`assets/scene-snapshot/index.html` 仅是配置基础页。仍不能宣称任何运行时成功。 | `D:/data/ideaSpace/rust/sgClaw/claw-new/docs/superpowers/specs/2026-04-08-95598-repair-city-dispatch-operation-analysis.md` |
| 户表失电-嘉峪关 | `jiayuguan-meter-outage` | 监测 | 监测户表失电事件，结合服务工单状态与历史日志识别待处理对象，并为自动处理链路提供输入。 | `scene.json`、`SKILL.md`、`scripts/collect_outage_events.js`、`D:/desk/智能体资料/大四区报告监测项/户表失电-嘉峪关_业务监测配置.txt`、`D:/desk/智能体资料/大四区报告监测项/户表失电-嘉峪关_自动处理配置.txt` | `code-confirmed`：packaged JS 现已直接实现输入驱动的 `monitor-snapshot` collector，可从 outage/service-order 数据计算 `pending/audit/processed`、比较 monitor/dispose logs、推导 `new_pending_ids`、输出 `success/partial/empty/blocked`，并携带 `workflow_rule_sources`、`config_base_page/config_base_role`、`identity_model` 元数据；更强的 outage collection、service-order enrichment、monitor/dispose log 比较、营销 token 依赖自动处理与派单分支直接存在于 desk 规则脚本。`contract-defined`：快照与下游自动处理需分开理解。`implementation intent exists but not rigorous / buggy`：监测 pending 列表用 `consNo`，处置去重用 `eventId`，身份模型不一致；短信通道只看到保留意图/注释代码。 | 本场景 desk workflow 证据也强于 packaged collector，且当前实际定时执行证据以 desk 规则脚本为主；`assets/scene-snapshot/index.html` 仅是配置基础页。必须保留身份不一致问题，不能把 `pending_ids/new_pending_ids` 写成已被严格统一定义。 | `D:/data/ideaSpace/rust/sgClaw/claw-new/docs/superpowers/specs/2026-04-08-jiayuguan-meter-outage-operation-analysis.md` |

## 当前状态汇总

### 1. 报表类场景的共同结论

- `fault-details-report`
- `jinchang-business-environment-weekly-report`
- `95598-weekly-monitor-report`

这 3 个 scene 当前最强直接证据都集中在“已打包脚本定义了 artifact schema / section template / 基础状态字段”。

因此，对这 3 个 scene 的严谨表述应是：

- `code-confirmed`：已存在结构模板、字段壳和分区定义
- `contract-defined`：存在明确的目标采集流程与质量要求
- `implementation intent exists but not rigorous / buggy`：运行时采集、周期对齐、状态细分、导出/日志等链路没有被 packaged JS 同等强度证实

换言之，它们当前主要是“结构化报表模板场景”，不应表述为“已验证的 live collector”。

### 2. 监测类场景的共同结论

- `95598-repair-city-dispatch`
- `jiayuguan-meter-outage`

这 2 个 scene 的情况与报表类不同：

- packaged JS collector 已具备输入驱动的 `monitor-snapshot` 归一化 / 比较逻辑
- 更强 workflow 证据主要存在于 desk 规则资产
- 规则资产直接展示了采集、比较、提醒、日志、派单等流程分支

因此，对这 2 个 scene 的严谨表述应是：

- `code-confirmed`：规则资产中确有较强监测/自动处理链路定义
- 但这仍只证明“规则层存在这些实现分支”
- 不得进一步写成“运行时已稳定成功”

### 3. 当前全局未闭合问题

- `fault-details-report`：`period` 与 `startTime/endTime` 的关系未闭合
- `jinchang-business-environment-weekly-report`：`region` 语义只在文案层出现，未形成稳定字段
- `95598-weekly-monitor-report`：`period` 与 `currentPeriod/cumulativePeriod`、period alignment 之间的关系未闭合
- `95598-repair-city-dispatch`：待处理分类规则存在 `status == "00" && status == "01"` bug
- `jiayuguan-meter-outage`：monitor pending 使用 `consNo`，dispose dedupe 使用 `eventId`，身份模型不一致

## 按证据等级整理的能力视图

### `code-confirmed`

- 报表 artifact / monitor snapshot 的基础结构壳
- 报表 scene 的固定 section/template 定义
- 两个监测 scene 规则资产中的采集、比较、日志、提醒、派单分支存在性

### `contract-defined`

- 报表类 scene 的目标采集流程、导出语义、质量约束
- 监测类 scene 的“快照成功”与“副作用成功”分离原则
- 周报类双周期/多来源/对齐语义

### `implementation intent exists but not rigorous / buggy`

- 报表类 scene 中对 live collector、period alignment、状态细分的实现意图
- `95598-repair-city-dispatch` 的 pending 分类 bug
- `jiayuguan-meter-outage` 的身份键不一致
- 若干下游通道存在定义或注释代码，但不足以提升为稳定现状

### `no direct evidence / candidate only`

- 统一 capability 名称本身
- 未来标准配置里的字段拆分方案
- `email` 等当前未见直接证据的候选通道

## 使用边界

本文件只用于帮助人快速理解“当前观察到的业务盘点状态”。如需：

- 看每个场景的证据出处与分级理由，读对应 operation-analysis 文档
- 看机器可读盘点结构，读 `2026-04-08-command-center-virtual-employee-inventory.json`
- 看未来目标配置结构提案，读 `2026-04-08-command-center-standard-config-structure.md`