docs: add command center analysis artifacts

Capture the command-center operation analyses, inventory outputs, and browser pipeline reference files produced during the current research pass so they can be reviewed from the branch. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-04-09 10:43:09 +08:00
parent 57b9be733d
commit 630190e4d3
12 changed files with 3125 additions and 0 deletions
--- a/docs/superpowers/specs/2026-04-08-95598-repair-city-dispatch-operation-analysis.md
+++ b/docs/superpowers/specs/2026-04-08-95598-repair-city-dispatch-operation-analysis.md
@@ -0,0 +1,217 @@
+# 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。
--- a/docs/superpowers/specs/2026-04-08-95598-weekly-monitor-report-operation-analysis.md
+++ b/docs/superpowers/specs/2026-04-08-95598-weekly-monitor-report-operation-analysis.md
@@ -0,0 +1,155 @@
+# 95598-weekly-monitor-report 操作分析
+
+## 1. 场景概述
+
+`95598-weekly-monitor-report` 对应“95598、12398及配网设备监控情况周统计”场景，目标是汇总 95598、12398 与配网设备多来源周统计并生成统一周报。根据 `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\scenes\95598-weekly-monitor-report\scene.json`、`D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\95598-weekly-monitor-report\SKILL.md` 与 `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\95598-weekly-monitor-report\scripts\collect_weekly_metrics.js`，当前最硬直接证据是：脚本定义了六个 section template、空 artifact、`period`、`status: "ok"` 与 `partial_reasons: []`，证据等级：`code-confirmed`。
+
+同时必须明确：当前 packaged script 对 artifact schema / section template 的定义，远强于对实时浏览器采集、多源周统计归并、双周期对齐或导出行为的证明。也就是说，本场景现在更接近“周报结构模板脚本”，而非“已被代码严格证明可跑通的 live browser collector”，证据等级：`code-confirmed`。
+
+## 2. 证据来源
+
+本分析统一只使用四个证据等级标签：`code-confirmed`、`contract-defined`、`implementation intent exists but not rigorous / buggy`、`no direct evidence / candidate only`。其中，脚本直接定义的 artifact schema / section template 归入 `code-confirmed`；未见脚本直接实现的双周期语义、采集逻辑与下游动作，不拔高于其对应较弱标签。
+
+1. `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\95598-weekly-monitor-report\scripts\collect_weekly_metrics.js`
+   - 直接定义六个 section template，并返回空 artifact，证据等级：`code-confirmed`。
+2. `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\95598-weekly-monitor-report\SKILL.md`
+   - 描述应读取 current-period 与 cumulative-period、校验会话、收集多来源 source groups、归一 section 数据，并在输出中返回两个周期、included source groups、period alignment issues 等；这更像运行契约与实现方向，证据等级以 `contract-defined` 与 `implementation intent exists but not rigorous / buggy` 为主。
+3. `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\scenes\95598-weekly-monitor-report\scene.json`
+   - 定义场景输入 `period`、依赖 `browser` / `multi-source` / `period-alignment` / `local-report-service`，动作包括 `query` / `collect-report` / `aggregate-sections` / `align-periods`，证据等级：`code-confirmed`。
+4. `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\95598-weekly-monitor-report\references\collection-flow.md`
+   - 明确入口页面提供两个日期范围：current-period 与 cumulative-period，并说明要先读两个范围，再收集 source groups、再按 section 归一，证据等级：`contract-defined`。
+5. `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\95598-weekly-monitor-report\references\data-quality.md`
+   - 规定完整结果、partial 规则、常见弱点和 empty/failure 区分，证据等级：`contract-defined`。
+6. `D:\data\ideaSpace\rust\sgClaw\claw-new\docs\superpowers\specs\2026-04-08-command-center-virtual-employee-inventory.json`
+   - 已将该场景整理为 `workflow`、`status_model`、`hidden_dependencies`、`open_questions` 等 command-center 视图；但其中部分是再抽象结果，不应反向拔高为实现证据，证据等级：`no direct evidence / candidate only`（仅限 inventory 不能单独证明 packaged script 已实现的部分）。
+
+## 3. 实际入口与运行边界
+
+实际入口已在 `scene.json` 固定：浏览器场景 `index.html`，技能工具名为 `95598-weekly-monitor-report.collect_weekly_metrics`，输出 artifact 为 `report-artifact`，这些都是 `code-confirmed`。
+
+运行边界方面出现了本场景最明显的不严谨点：
+
+- scene 与脚本都只保留一个 `period` 字段，证据等级：`code-confirmed`。
+- `SKILL.md`、`collection-flow.md` 与 inventory 整理结果都明确说明页面实际有 `current-period` 与 `cumulative-period` 两套输入，证据等级：`contract-defined`。
+- scene 还把 `period-alignment` 声明为依赖，并把 `align-periods` 声明为动作，但脚本没有任何相应执行逻辑，证据等级：`code-confirmed` 对元数据存在成立，而“已实现 period alignment”只能标为 `implementation intent exists but not rigorous / buggy`。
+
+因此，当前最严谨的边界判断是：上层元数据与参考文档都把本场景描述成“双周期、多来源、需周期对齐的 section 周报”，但 packaged script 实际只提供了一个空 artifact 模板壳，尚未证明 live collection 行为。
+
+## 4. 代码已证实的实际操作流程
+
+当前脚本中可直接证实的流程只有：
+
+1. 调用 `collectWeeklyMetrics(input)`。
+2. 读取 `input.period || ""` 写入返回对象的 `period`。
+3. 构造空主表：`columns: []`、`rows: []`。
+4. 基于 `SECTION_TEMPLATES` 复制出 6 个 section，且每个 section 初始 `rows: []`。
+5. 返回 `type: "report-artifact"`、`report_name`、`status: "ok"` 与 `partial_reasons: []`。
+
+这些都属于 `code-confirmed`。
+
+至于“读取 current-period / cumulative-period 两个日期范围”“验证多系统会话”“按 source group 采集 95598 / 12398 / 配网设备指标”“执行 period alignment”“导出周报或写报告日志”等行为，只在 `SKILL.md` 与 reference 中被描述，没有在 packaged script 中以可执行逻辑出现，因此不能算“代码已证实的实际操作流程”。
+
+## 5. 标准化抽象流程
+
+若做 command-center 的标准化抽象，可将本场景整理为：
+
+1. 接收周报任务请求。
+2. 解析 current-period 与 cumulative-period。
+3. 验证多系统访问与会话上下文。
+4. 按 source groups 收集周统计数据。
+5. 将结果归并到六个 section。
+6. 对 current-period 与 cumulative-period 做一致性校验或对齐。
+7. 生成 `report-artifact`。
+8. 视情况执行导出/日志等下游动作。
+
+其中第 5 步“六个 section schema 已存在”以及第 7 步“返回 artifact 壳”是 `code-confirmed`。第 2、3、4、6、8 步主要来自 skill/reference/scene 的目标流程描述，证据等级为 `contract-defined`；若要说这些步骤已被 packaged script 落地，则只能降为 `implementation intent exists but not rigorous / buggy`。
+
+## 6. 输入、上下文与依赖
+
+### 输入
+
+- `period` 是 scene 与脚本共享的显式输入，证据等级：`code-confirmed`。
+- `currentPeriod` / `cumulativePeriod`（或 current-period / cumulative-period）是 `SKILL.md`、reference 与 inventory 隐含/显式要求的真实业务输入，证据等级：`contract-defined`。
+- 这意味着当前输入建模存在明显冲突：统一配置只暴露 `period`，但场景语义其实依赖双周期，证据等级：`implementation intent exists but not rigorous / buggy`。
+
+### 运行上下文
+
+- `session`、多源系统账号/缓存 token、浏览器可见页面、周期对齐上下文等在 scene/reference 中被描述，scene 元数据层面的声明是 `code-confirmed`，具体业务语义是 `contract-defined`。
+- “period-alignment-context” 被 inventory 当作 runtime_context 整理出来，可视为对 scene/reference 的再抽象；作为建议结构可以保留，但不宜拔高成脚本已实现能力。
+
+### 依赖
+
+- `browser`、`multi-source`、`period-alignment`、`local-report-service` 在 `scene.json` 中可直接定位，证据等级：`code-confirmed`。
+- `/a_js/YPTAPI.js`、`http://localhost:13313/ReportServices/*` 等具体依赖来自 reference，证据等级：`contract-defined`。
+
+## 7. 输出结构
+
+当前脚本直接证实的输出结构包括：
+
+- `type: "report-artifact"`
+- `report_name: "95598-weekly-monitor-report"`
+- `period`
+- `columns: []`
+- `rows: []`
+- 6 个固定 section template
+- `status: "ok"`
+- `partial_reasons: []`
+
+以上全部属于 `code-confirmed`。
+
+六个已被脚本直接定义的 section 分别为：
+
+1. `fault-repair`
+2. `frequent-outage`
+3. `full-aperture-work-orders`
+4. `key-opinion-control`
+5. `device-monitoring`
+6. `proactive-dispatch`
+
+这些 section 中，前三个使用 `current_period`、`cumulative`、`year_over_year` 三类值列，后三个只使用 `value`，证据等级：`code-confirmed`。但这里也出现了建模歧义：
+
+- 输出 artifact 顶层只保留一个 `period`。
+- section 内部却已经暗示了 `current_period` 与 `cumulative` 的双周期视角。
+- skill/reference 又在文字上强调 current-period 与 cumulative-period 两个输入。
+
+因此，“双周期输入如何映射到 artifact 顶层 period 与 section 列结构”当前并不严谨，证据等级：`implementation intent exists but not rigorous / buggy`。
+
+## 8. 下游动作证据表
+
+| 下游动作 | 当前证据 | 证据等级 | 严谨结论 |
+| --- | --- | --- | --- |
+| 返回 section 化 `report-artifact` | `collect_weekly_metrics.js` 直接返回对象 | `code-confirmed` | 已有周报 artifact 模板壳，但仍为空数据。 |
+| 六类 section 模板存在 | 脚本直接定义 `SECTION_TEMPLATES` | `code-confirmed` | 只能确认输出分区 schema 存在，不能确认真实数据采集。 |
+| 双周期读取 | 只在 `SKILL.md` / `collection-flow.md` 中描述 | `contract-defined` | 契约明确需要 current-period 与 cumulative-period，但脚本未实现。 |
+| 多来源周统计采集 | 只在 skill/reference 中描述 | `contract-defined` | 有清晰目标流程，当前 packaged script 未直接证明。 |
+| period alignment | scene 动作/依赖 + skill/reference 说明 | `implementation intent exists but not rigorous / buggy` | 元数据和文档都表达了需要对齐，但脚本没有对齐逻辑，建模仍含糊。 |
+| 导出周报 | reference 提及 localhost report services | `contract-defined` | 只能确认存在下游服务约束，不能确认当前 skill 已执行导出。 |
+| 报告日志写入 | skill/reference 提及 report-log | `contract-defined` | 只有体系级概念证据，当前脚本无直接调用。 |
+| partial / blocked / empty 状态细分 | reference 有定义，脚本固定 `status: "ok"` | `implementation intent exists but not rigorous / buggy` | 状态模型意图明确，但 packaged script 尚未承载。 |
+
+## 9. 当前代码疑点 / 不严谨点
+
+1. `period` 与 `currentPeriod/cumulativePeriod` 的建模冲突最突出。scene 与 script 顶层只保留 `period`，但 skill/reference 明确要求双周期输入，前三个 section 的列结构也隐含双周期，这说明现有标准输入设计不严谨，证据等级：`implementation intent exists but not rigorous / buggy`。
+2. `period-alignment` 既被声明为依赖，也被列为动作 `align-periods`，但脚本没有任何对齐实现；因此“周期对齐能力已实现”不能成立，证据等级：`implementation intent exists but not rigorous / buggy`。
+3. 前三个 section 使用 `cumulative` 列名，而 skill/output 描述用的是 `cumulative period`；列名、输入名、顶层字段名之间没有形成统一建模，证据等级：`implementation intent exists but not rigorous / buggy`。
+4. `status` 固定为 `"ok"`，与 reference 对 partial / empty / blocked 的细分要求不一致，证据等级：`code-confirmed` 对现状成立。
+5. 尽管 scene/skill 明确是多来源周统计，但脚本完全没有 source group 采集或映射逻辑，因此“周统计 collector 已落地”不能提升为当前代码事实，证据等级：`no direct evidence / candidate only`（对 live collection 执行层而言）。
+
+## 10. 对 command-center 标准配置的修订建议
+
+1. 本场景应把标准输入从单一 `period` 修订为显式双周期结构，例如 `currentPeriod` 与 `cumulativePeriod`。若仍需要统一路由入口，可额外保留上层 `period` 摘要，但不能替代执行层双周期字段，证据等级：`implementation intent exists but not rigorous / buggy`。
+2. 对 `period-alignment` 建议在标准配置中拆成两部分：
+   - `period_model`: 双周期输入结构；
+   - `alignment_rule`: 这两组周期如何校验一致性。
+   当前 scene 只表达了需要对齐，但未给出严格模型，因此这是必要修订。
+3. 在 artifact 配置中区分：
+   - `implemented_section_templates`: 当前六个 section 已被脚本直接实现，证据等级：`code-confirmed`；
+   - `implemented_collection_logic`: 当前未被 packaged script 直接证明，需显式标低。
+4. 对前三个 section 的列名建议统一成更一致的配置命名，如 `current_period` / `cumulative_period` / `year_over_year`，避免脚本列名、skill 文本、标准配置三套口径混用。
+5. 状态模型建议拆成“契约层”和“实现层”，防止 command-center 把 `partial` / `blocked` 误当成当前 collector 已具备的稳定判定能力。
+
+## 11. 最终严谨结论
+
+关于 `95598-weekly-monitor-report`，当前最可靠的结论是：仓库已经存在一个六分区周报 artifact 模板实现，明确给出了 section 名称、列 schema、顶层 `period` 字段以及基础状态字段，证据等级：`code-confirmed`。
+
+但当前证据并不足以把它描述成“已严格实现双周期、多来源、含 period alignment 的真实浏览器周统计 collector”。相关双周期读取、source group 采集、period alignment、导出与日志行为，主要存在于 `SKILL.md`、`collection-flow.md`、`data-quality.md` 与 scene 元数据的目标描述中。尤其是 `period` vs `currentPeriod/cumulativePeriod` 以及 `period-alignment` 的建模仍明显含糊，说明本场景现在最适合被归类为“section schema 已定义，但 live browser collection 行为尚未被脚本严格证实”的 staged report scene。
--- a/docs/superpowers/specs/2026-04-08-command-center-evidence-grading.md
+++ b/docs/superpowers/specs/2026-04-08-command-center-evidence-grading.md
@@ -0,0 +1,203 @@
+# 指挥中心规格文档证据分级规则
+
+## 目的
+
+这份文档用于统一指挥中心相关规格文档中的证据表达方式，明确区分：
+
+- 已被代码或规则资产直接证实的事实
+- 已被外部接口或文档契约明确约束的事实
+- 代码中表达了实现方向，但实现质量、完整性或正确性仍不充分的内容
+- 当前没有直接证据、只能作为候选判断的内容
+
+目标不是让规格文档写得更保守，而是让“观察到的事实”“归纳后的结构”“目标态设计”之间的边界始终可追溯、可复核、可讨论。
+
+## 为什么必须分级
+
+如果不做证据分级，指挥中心文档很容易把三类内容混写在一起：
+
+1. 代码里已经存在并可直接定位的行为
+2. 为了便于抽象而做出的归一化整理
+3. 未来希望达成、但当前未被运行时或资产严格证明的目标结构
+
+混写的直接问题是：
+
+- 读者会把“推断出的整理结果”误认为“当前已实现事实”
+- 后续实现或重构时，无法判断某一条到底是在复述现状，还是在提出目标
+- 多份规格文档之间会出现证据强弱不一致、措辞口径不一致的问题
+
+因此，所有指挥中心规格文档都必须对关键判断显式标注证据等级。
+
+## 证据标签
+
+以下 4 个标签为唯一允许使用的标准标签，必须按原文书写，不得改写，不得替换为同义词。
+
+### 1. `code-confirmed`
+
+定义：该结论可由当前仓库中的代码、规则资产、静态配置或可直接定位的实现内容直接支持。
+
+适用场景：
+
+- 某个字段、流程步骤、状态分类、规则动作在代码或规则资产中可直接定位
+- 某个输出结构、配置项、动作通道已被实现内容明确写出
+- 某条成功路径虽然未证明线上真实跑通，但“存在该逻辑分支”这一事实已被代码直接证实
+
+使用边界：
+
+- `code-confirmed` 只证明“代码/资产中存在该实现或定义”
+- 不自动等于“生产可用”“运行时已验证成功”“端到端已闭环”
+
+### 2. `contract-defined`
+
+定义：该结论不是直接来自仓库实现，而是由当前被认可的接口契约、协议文档、外部约束文档明确规定。
+
+适用场景：
+
+- 浏览器侧/服务侧接口字段、消息格式、状态码语义由契约文档定义
+- 某一能力边界来自明确的外部 API 文档或经项目认可的集成约束
+
+使用边界：
+
+- `contract-defined` 证明“契约如此定义”
+- 不自动等于“本仓库已实现”
+- 如果代码实现与契约不一致，应分别描述，不得互相覆盖
+
+### 3. `implementation intent exists but not rigorous / buggy`
+
+定义：代码中已经出现实现意图、雏形或局部链路，但当前证据不足以把它写成稳定事实；或者已知实现不严谨、存在缺口、疑似有 bug、成功语义未被严格证明。
+
+适用场景：
+
+- 能看到相关函数、分支、调用点、配置项或动作名，但缺少足够证据证明其稳定成立
+- 逻辑存在，但状态语义混乱、异常处理不足、前后约束不完整
+- 只能证明“作者想做这件事”，不能证明“这件事已经被可靠实现”
+
+使用边界：
+
+- 该标签用于承认“实现方向存在”
+- 同时明确指出“不能把它提升为已确认事实”
+- 这是指挥中心文档中承接“代码里有影子，但证据不够硬”的唯一合法标签
+
+### 4. `no direct evidence / candidate only`
+
+定义：当前没有找到代码、规则资产、契约文档或其他直接证据；该内容只能作为候选结构、候选能力、候选拆分或待确认项。
+
+适用场景：
+
+- 为了统一配置结构而提出的候选字段
+- 为了后续架构演进而提出的候选能力名称
+- 仅由推测、命名习惯、经验归纳得到的判断
+
+使用边界：
+
+- 该标签明确表示“目前只是候选，不是事实”
+- 不能把它写成“已有但待接入”“已支持但未启用”之类更强说法，除非另有直接证据
+
+## 推荐表述模板
+
+### `code-confirmed`
+
+可用表述：
+
+- “根据当前代码/规则资产，可直接确认……，证据等级：`code-confirmed`。”
+- “文档中的……来自现有实现直接证据，证据等级：`code-confirmed`。”
+- “这里只能确认代码层存在该成功路径/动作定义，证据等级：`code-confirmed`；不代表运行时已验证。”
+
+### `contract-defined`
+
+可用表述：
+
+- “根据当前接口契约，……被定义为……，证据等级：`contract-defined`。”
+- “该字段/消息结构来自认可的集成契约，证据等级：`contract-defined`。”
+- “这里描述的是契约约束，不等于仓库内实现已完成，证据等级：`contract-defined`。”
+
+### `implementation intent exists but not rigorous / buggy`
+
+可用表述：
+
+- “当前实现中可以看到……的意图，但证据尚不足以将其写成稳定事实，证据等级：`implementation intent exists but not rigorous / buggy`。”
+- “代码存在相关链路，但实现不够严谨/疑似有缺口，因此仅标为 `implementation intent exists but not rigorous / buggy`。”
+- “目前最多只能确认作者试图支持……，不能确认其已被可靠实现，证据等级：`implementation intent exists but not rigorous / buggy`。”
+
+### `no direct evidence / candidate only`
+
+可用表述：
+
+- “……目前没有直接证据，只能作为候选项，证据等级：`no direct evidence / candidate only`。”
+- “该拆分/命名属于归一化建议，不代表现状事实，证据等级：`no direct evidence / candidate only`。”
+- “除非后续补到代码或契约证据，否则这里只能保持为 `no direct evidence / candidate only`。”
+
+## 禁止表述模式
+
+以下表述在指挥中心规格文档中禁止使用，除非同时给出更低证据等级并明确限定范围。
+
+### 1. 禁止把代码存在误写为运行时已验证
+
+禁止示例：
+
+- “系统已经稳定支持……”
+- “该链路已完成闭环……”
+- “运行时已证明可以成功……”
+
+问题：这些表述把“代码里有逻辑”错误提升成“真实运行已被验证”。
+
+### 2. 禁止把推断结构误写为既有事实
+
+禁止示例：
+
+- “当前配置结构就是……”
+- “系统已有统一能力模型……”
+- “所有任务已经按该 schema 实现……”
+
+问题：如果只是为了整理而归纳出的标准结构，应标为候选或目标态，不能写成现状。
+
+### 3. 禁止使用模糊强化词替代证据标签
+
+禁止示例：
+
+- “基本可以认为……”
+- “大概率就是……”
+- “看起来已经支持……”
+- “应该算是实现了……”
+
+问题：模糊判断会绕开证据分级，导致读者无法判断结论强度。
+
+### 4. 禁止自造同义标签或混用近义词
+
+禁止示例：
+
+- “代码已确认”
+- “契约已定义”
+- “半实现”
+- “待验证”
+- “候选”
+
+问题：这些中文近义词会破坏跨文档一致性。必须使用本文规定的 4 个精确标签原文。
+
+## 示例：`95598-repair-city-dispatch`
+
+示例结论：
+
+- 对 `95598-repair-city-dispatch` 而言，音频提醒、短信/消息提醒、外呼、处置日志等成功路径行为，如果能够在规则资产或实现内容中直接定位，应写为 `code-confirmed`。
+- 但这只能说明“代码或规则里存在这些成功路径定义”。
+- 不能据此直接写成“运行时已经稳定成功触发音频/短信/外呼/处置日志”。
+- 如果当前没有端到端运行验证证据，那么“运行时成功”只能写为 `implementation intent exists but not rigorous / buggy`，或者在证据更弱时写为 `no direct evidence / candidate only`；不能提升为 `code-confirmed`。
+
+推荐写法：
+
+“在 `95598-repair-city-dispatch` 中，音频提醒、短信/消息提醒、外呼、处置日志相关成功路径可在规则资产中直接定位，因此这些‘规则层已定义的成功路径行为’可标注为 `code-confirmed`。但目前没有同等强度证据证明这些动作在真实运行时已稳定成功，因此‘运行时成功已验证’这一结论不能标为 `code-confirmed`；在缺少严格运行证据时，应标为 `implementation intent exists but not rigorous / buggy`。”
+
+## 执行规则
+
+- 所有指挥中心相关规格文档，必须使用本文定义的 4 个精确标签。
+- 不允许使用任何同义词、中文替代词、缩写或自定义等级名。
+- 一条关键结论如果没有证据等级，就视为表达不合格。
+- 当同一主题同时涉及“代码事实”和“目标结构”时，必须拆句分别标注，不能合并成一个模糊结论。
+
+## 最短落地准则
+
+写每一条关键判断前，先问两个问题：
+
+1. 我是在复述当前已被直接证据支持的事实，还是在做归一化整理/目标设计？
+2. 我手上的证据，到底支撑的是代码存在、契约约束、实现意图，还是根本没有直接证据？
+
+只有先回答这两个问题，指挥中心规格文档才能保持严格、可复核和可持续重写。
--- a/docs/superpowers/specs/2026-04-08-command-center-standard-config-structure.md
+++ b/docs/superpowers/specs/2026-04-08-command-center-standard-config-structure.md
@@ -0,0 +1,639 @@
+# 指挥中心虚拟员工标准配置清单建议结构
+
+> 免责声明：本文件描述的是“未来可采用的规范化目标配置结构”，不是当前 staged runtime 已稳定实现的结构，也不是对现状的直接复述。文中所有“目标 schema 字段”都必须与当前证据分级文档一起阅读；凡缺乏静态资产直接支撑的字段，只能视为 normalization choice 或 open / candidate 字段，不能表述为当前已稳定存在。
+
+## 目标
+
+这份结构文档的用途，是把当前 evidence-graded 现状文档中的信息，逐步映射为后续可维护、可扩展、可复用的目标配置清单。
+
+因此必须同时保持两条边界：
+
+1. 当前已观察到的事实，来自 evidence-graded current-state docs。
+2. 这里提出的统一 schema，则是为后续 command-center 配置治理而做的 normalization proposal。
+
+它们不能混写，更不能把 normalization proposal 误写成当前实现事实。
+
+---
+
+## 一、当前证据文档与目标配置的关系
+
+当前已经存在三类文档角色：
+
+1. `2026-04-08-command-center-virtual-employee-inventory-table.md`
+   - 作用：给人读的 current-state 总览
+   - 性质：当前观察结果，不是配置 schema
+2. `2026-04-08-command-center-virtual-employee-inventory.json`
+   - 作用：给机器读的 current-state inventory
+   - 性质：机器可消费的盘点结果，不是目标配置
+3. 各 scene 的 `*-operation-analysis.md`
+   - 作用：记录每个场景的证据来源、强弱、已知问题和边界
+   - 性质：最关键的证据支撑层
+
+本文件提出的目标配置结构，是在这些 current-state 文档之上的“规范化目标层”。
+
+### 映射原则
+
+- operation-analysis 文档中的 `code-confirmed` 结论，可优先映射为目标 schema 中的“evidence-derived fields”。
+- `contract-defined` 结论，可映射为“declared / contract-backed fields”，但不能默认等于当前 runtime 已实现。
+- `implementation intent exists but not rigorous / buggy` 的内容，应进入目标 schema 的 `known_issues`、`implementation_gap`、`notes` 或 `open_questions`，而不是被包装成稳定主字段。
+- `no direct evidence / candidate only` 的内容，只能作为 normalization choice、candidate field 或未来扩展项保留。
+
+简言之：evidence-graded current-state docs 告诉我们“现在能严谨说什么”，本文件只负责说明“未来若要统一配置，可怎样承接这些信息”。
+
+---
+
+## 二、推荐文件组织
+
+```text
+command-center/
+  employee.json
+  capabilities.json
+  tasks/
+    fault-details-report.json
+    jinchang-business-environment-weekly-report.json
+    95598-weekly-monitor-report.json
+    95598-repair-city-dispatch.json
+    jiayuguan-meter-outage.json
+```
+
+### 文件职责
+
+- `employee.json`
+  - 描述这个虚拟员工是谁、职责范围是什么、默认采用什么证据口径
+- `capabilities.json`
+  - 维护归一化能力词表
+  - 明确哪些能力来自现有证据，哪些只是规范化命名
+- `tasks/*.json`
+  - 每个场景一份目标配置
+  - 承接当前证据与未来标准字段的映射关系
+
+### 为什么仍然推荐三层拆分
+
+这类拆分仍然成立，但要加一条限定：
+
+- 这是一种 target architecture proposal
+- 不是当前仓库已存在的稳定目录结构
+- 尤其 `capabilities.json` 代表“统一能力词表”的目标态，而不是当前 staged assets 已实现的统一能力注册表
+
+因此，三层拆分本身属于 normalization choice，证据等级不应高于 `no direct evidence / candidate only`，除非未来真的落地成文件结构。
+
+---
+
+## 三、`employee.json` 目标结构
+
+### 3.1 推荐示例
+
+```json
+{
+  "id": "command-center-virtual-employee",
+  "name": "指挥中心虚拟员工",
+  "domain": "电力业务指挥中心",
+  "positioning": "负责业务监测、统计报表、异常识别与后续提醒/处置支撑的虚拟运营员工",
+  "mission": [
+    "采集业务数据并生成结构化报表",
+    "监测工单/事件并识别待处理对象",
+    "比较历史记录识别新增待办",
+    "为提醒、外呼、自动派单、自动处理等下游动作提供输入"
+  ],
+  "task_ids": [
+    "fault-details-report",
+    "jinchang-business-environment-weekly-report",
+    "95598-weekly-monitor-report",
+    "95598-repair-city-dispatch",
+    "jiayuguan-meter-outage"
+  ],
+  "default_evidence_model": [
+    "code-confirmed",
+    "contract-defined",
+    "implementation intent exists but not rigorous / buggy",
+    "no direct evidence / candidate only"
+  ],
+  "default_status_model": [
+    "success",
+    "partial",
+    "empty",
+    "blocked"
+  ]
+}
+```
+
+### 3.2 字段分层说明
+
+#### A. 可直接由当前证据承接的字段
+
+- `name`
+- `domain`
+- `task_ids`（前提是仅映射当前已盘点的 5 个 scene）
+- `default_evidence_model`
+
+这些字段之所以较容易承接，是因为 current-state inventory 已经稳定整理出对应对象和场景清单。
+
+但仍要注意：这只是“可从当前文档整理得到”，不是说仓库里已经存在一个运行中的 `employee.json`。
+
+#### B. normalization choices
+
+- `id`
+- `positioning`
+- `mission`
+- `default_status_model`
+
+这些字段主要是为了让目标配置更易治理、更可复用，属于规范化整理，不应表述为 staged runtime 现状。
+
+#### C. open / candidate 字段
+
+建议预留但暂不稳定化：
+
+- `default_runtime_requirements`
+- `default_result_types`
+- `default_downstream_policy`
+- `org_scope`
+- `region_scope`
+
+原因是：当前不同 scene 在“上下文依赖、输出类型、地区语义、下游策略”上并不一致，过早把这些做成员工级稳定字段会拔高现状。
+
+---
+
+## 四、`capabilities.json` 目标结构
+
+### 4.1 推荐示例
+
+```json
+{
+  "catalog_version": 1,
+  "evidence_method": "evidence-graded",
+  "core": [
+    {
+      "id": "browser-collection",
+      "name": "浏览器采集",
+      "kind": "normalized-capability",
+      "evidence_basis": "derived-from-multiple-scenes"
+    },
+    {
+      "id": "report-generation",
+      "name": "报表生成",
+      "kind": "normalized-capability",
+      "evidence_basis": "derived-from-report-scenes"
+    },
+    {
+      "id": "monitor-snapshot",
+      "name": "监测快照",
+      "kind": "normalized-capability",
+      "evidence_basis": "derived-from-monitor-scenes"
+    }
+  ],
+  "channels": [
+    {
+      "id": "audio-remind",
+      "name": "音频提醒",
+      "kind": "normalized-channel",
+      "observed_in": [
+        "95598-repair-city-dispatch",
+        "jiayuguan-meter-outage"
+      ]
+    },
+    {
+      "id": "message-remind",
+      "name": "消息提醒",
+      "kind": "normalized-channel",
+      "observed_in": [
+        "95598-repair-city-dispatch"
+      ],
+      "notes": "在 jiayuguan-meter-outage 中只看到保留意图，不应等同视为稳定现状。"
+    }
+  ],
+  "actions": [
+    {
+      "id": "auto-dispatch",
+      "name": "自动派单",
+      "kind": "normalized-action"
+    }
+  ]
+}
+```
+
+### 4.2 字段分层说明
+
+#### A. 可由当前证据承接的字段
+
+- `observed_in`
+- `notes`
+- `evidence_basis`
+
+如果后续真的落地 `capabilities.json`，最应该优先保留的不是“能力名本身”，而是能力和 scene 之间的 evidence mapping。因为当前场景的能力证据强弱明显不同：
+
+- 3 个报表 scene 多为 schema/template stub
+- 2 个监测 scene 更强 workflow 主要来自规则资产
+- `message-remind`、`callout`、`auto-dispatch` 等通道在不同 scene 中强度不一致
+
+#### B. normalization choices
+
+- `core`
+- `channels`
+- `actions`
+- `id`
+- `name`
+- `kind`
+
+这些统一词表字段本身就是规范化选择。当前没有直接证据表明仓库中已经存在统一 capability registry。
+
+#### C. open / candidate 字段
+
+建议保持候选态：
+
+- `required_contexts`
+- `result_semantics`
+- `stability_level`
+- `implemented_by`
+- `runtime_owner`
+
+这些字段看起来很有用，但 staged assets 还不足以稳定支撑它们。
+
+### 4.3 对能力词表的关键限制
+
+- 不要把 `report-export`、`audio-remind`、`callout` 之类词条本身写成“已全局统一支持”。
+- 不要因为某个规则资产里出现了调用，就把它提升为所有 scene 的稳定 capability。
+- `email` 目前仍应保持 candidate，不应进入“已支持通道”集合。
+
+---
+
+## 五、`tasks/*.json` 目标结构
+
+### 5.1 统一推荐骨架
+
+```json
+{
+  "id": "95598-repair-city-dispatch",
+  "name": "95598抢修-市指",
+  "category": "monitor",
+  "current_state": {
+    "primary_evidence_summary": "rule assets stronger than packaged JS stub",
+    "source_refs": [],
+    "known_issues": []
+  },
+  "binding": {
+    "scene_id": "95598-repair-city-dispatch",
+    "skill_package": "95598-repair-city-dispatch",
+    "tool": "collect_repair_orders"
+  },
+  "trigger": {
+    "observed": {},
+    "normalized": {},
+    "open_questions": []
+  },
+  "inputs": {
+    "observed": {},
+    "normalized": {},
+    "open_questions": []
+  },
+  "systems": {
+    "observed": {},
+    "normalized": {},
+    "open_questions": []
+  },
+  "workflow": {
+    "observed": [],
+    "normalized": [],
+    "open_questions": []
+  },
+  "result": {
+    "observed": {},
+    "normalized": {},
+    "open_questions": []
+  },
+  "downstream_effects": {
+    "observed": [],
+    "normalized": [],
+    "open_questions": []
+  },
+  "required_capabilities": {
+    "normalized": [],
+    "open_questions": []
+  },
+  "status_model": {
+    "declared": {},
+    "implemented_notes": []
+  },
+  "evidence_grades": {},
+  "open_questions": []
+}
+```
+
+这个骨架的核心目标不是“把所有字段都填满”，而是强制区分：
+
+- `observed`
+- `normalized`
+- `open_questions`
+
+这样可避免把 future-facing target config 误写成 current-state。
+
+---
+
+## 六、报表类任务在目标 schema 中应如何表达
+
+适用对象：
+
+- `fault-details-report`
+- `jinchang-business-environment-weekly-report`
+- `95598-weekly-monitor-report`
+
+### 6.1 当前证据对目标 schema 的约束
+
+这 3 个任务当前最强直接证据主要是：
+
+- 已有 `report-artifact` 结构壳
+- 已有 section/template 定义
+- 已有 `status` / `partial_reasons` 字段壳
+
+但它们共同缺少同等强度的 live collection 证据。因此若采用该目标 schema，建议保留一个明确的 current-state 提示，例如：
+
+```json
+"current_state": {
+  "primary_evidence_summary": "packaged script mainly confirms artifact schema / section template; live collection remains contract-defined or weaker"
+}
+```
+
+### 6.2 报表类字段分层
+
+#### A. evidence-derived fields
+
+- `binding.scene_id`
+- `binding.skill_package`
+- `binding.tool`
+- `result.observed.artifact_type`
+- `result.observed.key_fields`
+- `systems.observed.browser_pages`
+- `source_refs`
+
+#### B. normalization choices
+
+- `trigger.normalized.natural_language_examples`
+- `inputs.normalized.runtime_context`
+- `workflow.normalized`
+- `required_capabilities.normalized`
+- `downstream_effects.normalized`
+
+#### C. open / candidate fields
+
+- `period_model`
+- `section_semantics`
+- `region_scope`
+- `alignment_rule`
+- `report_export_policy`
+
+### 6.3 各报表任务的特别约束
+
+#### `fault-details-report`
+
+- 若采用该目标 schema，建议对外保留 `period`，但执行层最好允许展开为 `startTime/endTime`。
+- `summary-sheet` 建议标记为“template confirmed”，不要误写成“summary derivation implemented”。
+
+#### `jinchang-business-environment-weekly-report`
+
+- 若采用该目标 schema，建议把“4 个固定 section 模板已观察到”与“真实多源采集已实现”分开表达。
+- `region` 是否成为稳定字段，目前仍是 open item。
+
+#### `95598-weekly-monitor-report`
+
+- 若采用该目标 schema，建议预留 `currentPeriod` 与 `cumulativePeriod`，但必须注明这属于对当前建模冲突的修正提案。
+- `period alignment` 建议单列为 schema group 或 `alignment_rule`，而不是默认已经在 runtime 中稳定存在。
+
+---
+
+## 七、监测类任务在目标 schema 中应如何表达
+
+适用对象：
+
+- `95598-repair-city-dispatch`
+- `jiayuguan-meter-outage`
+
+### 7.1 当前证据对目标 schema 的约束
+
+这两个任务与报表类不同：
+
+- packaged JS collector 已具备输入驱动的 `monitor-snapshot` 归一化 / 比较逻辑，并会附带规则来源、配置基础页角色、已知问题/身份模型说明
+- 更强 workflow 证据主要来自规则资产（当前按盘点口径以 `D:/desk/智能体资料/大四区报告监测项/*.txt` 规则脚本为主）
+- `assets/scene-snapshot/index.html` 仅属于配置基础层，不应计入 workflow 主执行证据
+
+因此若采用该目标 schema，建议显式区分：
+
+```json
+"current_state": {
+  "packaged_stub_strength": "code-confirmed",
+  "rule_asset_workflow_strength": "code-confirmed",
+  "notes": "workflow evidence is stronger in rule assets than in packaged JS stub"
+}
+```
+
+### 7.2 监测类字段分层
+
+#### A. evidence-derived fields
+
+- `binding.*`
+- `inputs.observed.explicit`
+- `systems.observed.upstream_apis`
+- `systems.observed.local_services`
+- `workflow.observed`
+- `result.observed`
+- `downstream_effects.observed`
+- `current_state.known_issues`
+
+#### B. normalization choices
+
+- `workflow.normalized`
+- `required_capabilities.normalized`
+- `canonical_snapshot_fields`
+- `effect_channels`
+
+#### C. open / candidate fields
+
+- `identity_model`
+- `downstream_policy`
+- `alert_channel_split`
+- `auto_processing_policy`
+- `dependency_promotion_rules`
+
+### 7.3 各监测任务的特别约束
+
+#### `95598-repair-city-dispatch`
+
+若采用该目标 schema，建议保留以下说明：
+
+- workflow 强证据主要来自规则资产（当前盘点以 `D:/desk/智能体资料/大四区报告监测项/95598抢修-市指_业务检测配置.txt` 与 `D:/desk/智能体资料/大四区报告监测项/95598抢修-市指_自动处理配置.txt` 为主），而不是 packaged JS stub
+- `pending` 分类存在 `status == "00" && status == "01"` bug
+- `pending_ids/new_pending_ids` 更像 canonical target fields，而不是当前规则层已严格同名产出字段
+
+建议把这个 bug 直接纳入：
+
+```json
+"current_state": {
+  "known_issues": [
+    "pending classification bug: status == \"00\" && status == \"01\""
+  ]
+}
+```
+
+#### `jiayuguan-meter-outage`
+
+若采用该目标 schema，建议保留以下说明：
+
+- workflow 强证据主要来自规则资产（当前盘点以 `D:/desk/智能体资料/大四区报告监测项/户表失电-嘉峪关_业务监测配置.txt` 与 `D:/desk/智能体资料/大四区报告监测项/户表失电-嘉峪关_自动处理配置.txt` 为主），而不是 packaged JS stub
+- marketing token 是自动处理链路的强依赖
+- monitor pending list 用 `consNo`，dispose dedupe 用 `eventId`，身份模型不一致
+
+因此在该目标 schema 提案中，建议单列：
+
+```json
+"identity_model": {
+  "monitor_pending_identity": "consNo",
+  "dispose_dedupe_identity": "eventId",
+  "status": "implementation intent exists but not rigorous / buggy"
+}
+```
+
+这类字段不应被伪装成“已经统一好的 snapshot identity model”。
+
+---
+
+## 八、推荐统一字段清单与证据边界
+
+下面给出一个更严格的统一字段视图。
+
+### 1. 元数据层
+
+较适合作为稳定 target schema 的字段：
+
+- `id`
+- `name`
+- `category`
+- `binding.scene_id`
+- `binding.skill_package`
+- `binding.tool`
+
+其中：
+
+- `binding.*` 更偏 evidence-derived
+- `id/name/category` 更偏 normalization choice
+
+### 2. 现状映射层
+
+建议新增并长期保留：
+
+- `current_state.primary_evidence_summary`
+- `current_state.source_refs`
+- `current_state.known_issues`
+- `current_state.notes`
+
+这是本次重写后最重要的新增设计点之一。没有这层，target schema 很容易再次把“目标结构”和“现状证据”混在一起。
+
+### 3. 触发层
+
+- `trigger.observed`
+- `trigger.normalized`
+- `trigger.open_questions`
+
+### 4. 输入层
+
+- `inputs.observed`
+- `inputs.normalized`
+- `inputs.open_questions`
+
+### 5. 系统层
+
+- `systems.observed`
+- `systems.normalized`
+- `systems.open_questions`
+
+### 6. 流程层
+
+- `workflow.observed`
+- `workflow.normalized`
+- `workflow.open_questions`
+
+### 7. 结果层
+
+- `result.observed`
+- `result.normalized`
+- `result.open_questions`
+
+### 8. 下游动作层
+
+- `downstream_effects.observed`
+- `downstream_effects.normalized`
+- `downstream_effects.open_questions`
+
+### 9. 能力层
+
+- `required_capabilities.normalized`
+- `required_capabilities.open_questions`
+
+### 10. 证据层
+
+- `evidence_grades`
+- `source_refs`
+
+### 11. 人工确认层
+
+- `open_questions`
+- `known_issues`
+
+---
+
+## 九、为什么这次建议在 target schema 中显式保留“现状层”
+
+旧版结构容易出现的问题是：
+
+- 把 aggregate inventory 直接写成“标准配置已经长这样”
+- 把 `required_capabilities`、`downstream_effects` 这样的归一化字段误读成 runtime 现状
+- 把规则资产中的 workflow 直接等价成 packaged script 实现
+
+因此这次建议最关键的修订不是多加几个字段，而是要求 target schema 同时携带：
+
+1. `observed current state`
+2. `normalized target structure`
+3. `open / candidate items`
+
+只有这样，后续继续扩展新 scene 时，文档才不会再次把三类内容混在一起。
+
+---
+
+## 十、建议的落地顺序
+
+1. 先把 current-state inventory 保持为证据分级后的事实盘点。
+2. 再基于 inventory 生成目标态 `employee.json` / `capabilities.json` / `tasks/*.json` 草案。
+3. 落地草案时，强制为每个 major group 补齐：
+   - `observed`
+   - `normalized`
+   - `open_questions`
+4. 先优先收敛已知关键不严谨点：
+   - `fault-details-report` 的 `period` vs `startTime/endTime`
+   - `95598-weekly-monitor-report` 的双周期 / period alignment
+   - `95598-repair-city-dispatch` 的 pending classification bug
+   - `jiayuguan-meter-outage` 的 `consNo` vs `eventId` 身份不一致
+5. 最后再考虑是否把能力词表与 target config 接入真实消费链路。
+
+注意：在这些问题未收敛前，不应把目标配置字段写成“已经稳定”。
+
+---
+
+## 十一、推荐结论
+
+如果目标是形成“指挥中心虚拟员工的标准配置清单”，那么未来仍然可以采用：
+
+- `employee.json`
+- `capabilities.json`
+- `tasks/*.json`
+
+这样的三层结构。
+
+但和旧版不同的是，这套结构必须显式承认：
+
+- 它是 target architecture proposal，不是现状复述
+- 每个 major schema group 都要区分 evidence-derived fields、normalization choices、open / candidate fields
+- evidence-graded current-state docs 才是现状依据
+- 报表类 3 个 scene 当前主要是 schema/template stub
+- `95598-repair-city-dispatch` 与 `jiayuguan-meter-outage` 的 workflow 强证据主要在规则资产
+- `95598-repair-city-dispatch` 存在 pending classification bug
+- `jiayuguan-meter-outage` 存在 `consNo` / `eventId` 身份不一致问题
+- 任何地方都不应宣称 runtime verification
+
+只有在保持这些边界的前提下，这份“标准配置结构”才是严谨可持续的目标态提案，而不是再次把现状、推断和目标混写在一起。
--- a/docs/superpowers/specs/2026-04-08-command-center-virtual-employee-inventory-table.md
+++ b/docs/superpowers/specs/2026-04-08-command-center-virtual-employee-inventory-table.md
@@ -0,0 +1,121 @@
+# 指挥中心虚拟员工业务盘点清单（表格版）
+
+> 说明：本文件是“当前状态总览”，不是目标配置 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`
--- a/docs/superpowers/specs/2026-04-08-command-center-virtual-employee-inventory-table.rebuilt.xlsx
+++ b/docs/superpowers/specs/2026-04-08-command-center-virtual-employee-inventory-table.rebuilt.xlsx
--- a/docs/superpowers/specs/2026-04-08-command-center-virtual-employee-inventory-table.xlsx
+++ b/docs/superpowers/specs/2026-04-08-command-center-virtual-employee-inventory-table.xlsx
--- a/docs/superpowers/specs/2026-04-08-command-center-virtual-employee-inventory.json
+++ b/docs/superpowers/specs/2026-04-08-command-center-virtual-employee-inventory.json
--- a/docs/superpowers/specs/2026-04-08-fault-details-report-operation-analysis.md
+++ b/docs/superpowers/specs/2026-04-08-fault-details-report-operation-analysis.md
@@ -0,0 +1,142 @@
+# fault-details-report 操作分析
+
+## 1. 场景概述
+
+`fault-details-report` 对应“故障明细”场景，目标表述为查询故障明细并生成包含明细与汇总分区的结构化报表。根据 `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\scenes\fault-details-report\scene.json`、`D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\fault-details-report\SKILL.md` 与 `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\fault-details-report\scripts\collect_fault_details.js`，当前最强直接证据在于：已打包脚本明确了报表 artifact 的列结构、汇总 section 名称、空结果形态与 `status: "ok"` 默认值，证据等级：`code-confirmed`。
+
+但同一批证据并没有展示真实浏览器页面抓取、请求触发、行级归一化或汇总派生的实际执行代码。也就是说，当前 packaged script 对 artifact schema / section template 的定义，明显强于对实时浏览器采集行为的证明，证据等级：`code-confirmed`。
+
+## 2. 证据来源
+
+本分析统一只使用四个证据等级标签：`code-confirmed`、`contract-defined`、`implementation intent exists but not rigorous / buggy`、`no direct evidence / candidate only`。其中，脚本直接定义的 artifact schema / section template 归入 `code-confirmed`；未见脚本直接实现的运行语义与下游动作，不拔高于其对应较弱标签。
+
+1. `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\fault-details-report\scripts\collect_fault_details.js`
+   - 直接定义 `DETAIL_COLUMNS`、`SUMMARY_COLUMNS`、返回对象字段、空 `rows`、空 `sections[0].rows`、`status: "ok"`、`partial_reasons: []`，证据等级：`code-confirmed`。
+2. `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\fault-details-report\SKILL.md`
+   - 说明预期工作流为读取时间范围、收集原始故障明细、按规范列顺序归一、派生汇总 sheet、返回 artifact；这是技能说明与目标运行契约，能证明意图与期望输出，但不能单独证明脚本已实现全部步骤，整体证据等级以 `contract-defined` 与 `implementation intent exists but not rigorous / buggy` 并存描述更严谨。
+3. `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\scenes\fault-details-report\scene.json`
+   - 定义场景输入为 `period`、依赖为 `browser` / `report-history` / `local-report-service`、动作包括 `query` / `collect-report` / `build-summary-section`，属于场景元数据定义，证据等级：`code-confirmed`。
+4. `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\fault-details-report\references\collection-flow.md`
+   - 给出“读取开始结束时间、触发 repair-order query、收集明细、按 `excleIni[0].cols` 归一、派生 summary-sheet、再返回 artifact”的参考流程；它定义了预期采集语义，证据等级：`contract-defined`。
+5. `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\fault-details-report\references\data-quality.md`
+   - 给出必填列、可空列、summary 派生期望、partial 规则与 empty/failure 区分，属于质量约束参考，证据等级：`contract-defined`。
+6. `D:\data\ideaSpace\rust\sgClaw\claw-new\docs\superpowers\specs\2026-04-08-command-center-virtual-employee-inventory.json`
+   - 已把该场景整理为 `workflow`、`result.key_fields`、`status_model` 与 `open_questions`，可作为当前 command-center 侧归纳结果，但其中部分内容是对 scene/skill/reference 的再整理，不应反向当作新实现证据；证据等级：`no direct evidence / candidate only`（仅限 inventory 不能单独证明 packaged script 已实现的部分）。
+
+## 3. 实际入口与运行边界
+
+实际入口已在 `scene.json` 中声明为浏览器场景 `index.html`，技能包工具名为 `fault-details-report.collect_fault_details`，artifact 类型为 `report-artifact`，这些都是当前仓库可直接定位的定义，证据等级：`code-confirmed`。
+
+运行边界方面：
+
+- 场景元数据只声明了 `inputs: ["period"]`，证据等级：`code-confirmed`。
+- 参考流程却明确要求从页面 datetime range control 读取 `start` / `end` 时间，证据等级：`contract-defined`。
+- 因而“外部统一输入叫 `period`，但页面真实业务输入更像 `startTime/endTime` 二元组”这一判断是当前最严谨的归纳，且 inventory 文件也把它列入 `open_questions`，证据等级：`implementation intent exists but not rigorous / buggy`。
+
+还要强调：当前可直接运行的打包脚本并未包含浏览器操作、请求调用、页面解析或 localhost 导出调用代码，因此它的实际边界更接近“返回一个预定义空 artifact 的 schema stub”，而不是“已严格实现端到端浏览器采集器”，证据等级：`code-confirmed`。
+
+## 4. 代码已证实的实际操作流程
+
+当前代码真正能严格确认的流程只有以下最小闭环：
+
+1. 调用 `collectFaultDetails(input)`。
+2. 读取 `input.period || ""` 填入返回对象的 `period` 字段。
+3. 将 `DETAIL_COLUMNS` 写入主表 `columns`。
+4. 将空数组写入主表 `rows`。
+5. 构造一个名为 `summary-sheet` 的 section，并写入 `SUMMARY_COLUMNS` 与空 `rows`。
+6. 返回 `type: "report-artifact"`、`report_name: "fault-details-report"`、`status: "ok"`、`partial_reasons: []`。
+
+以上每一步都能在 `collect_fault_details.js` 中直接定位，证据等级：`code-confirmed`。
+
+至于以下操作：读取页面时间、触发 repair-order 查询、抓取故障行、归一字段、按明细派生汇总、判断 partial/empty/blocked、调用导出服务或报告日志服务，目前在 packaged script 中没有对应实现代码，只在 skill/reference 文本里出现，证据等级最多是 `contract-defined` 或 `implementation intent exists but not rigorous / buggy`，不能写成当前代码已证实的实际流程。
+
+## 5. 标准化抽象流程
+
+若为 command-center 做严格抽象，当前更合理的标准化流程应写成：
+
+1. 解析外部任务输入。
+2. 将业务时间范围映射到页面查询参数。
+3. 执行浏览器态查询并收集故障明细行。
+4. 按约定列顺序归一主表数据。
+5. 基于明细结果派生 `summary-sheet`。
+6. 生成 `report-artifact`。
+7. 如有需要再执行导出/日志等下游动作。
+
+其中第 6 步“生成具有主表+summary-sheet 的 artifact 结构”可由脚本直接支撑，证据等级：`code-confirmed`。第 2、3、4、5、7 步主要来自场景说明与 reference 文档，不是当前脚本已实现事实，证据等级应分别按 `contract-defined` 或 `implementation intent exists but not rigorous / buggy` 标注。
+
+## 6. 输入、上下文与依赖
+
+### 输入
+
+- `period` 被 scene 元数据与脚本入参直接使用，证据等级：`code-confirmed`。
+- “页面实际读取开始时间与结束时间”来自 `references/collection-flow.md` 和 `SKILL.md` 的 workflow 描述，证据等级：`contract-defined`。
+- 因此 `period` 与 `startTime/endTime` 的关系当前并不严谨：很可能 `period` 只是上层统一抽象，而底层真实 collector 需要双时间字段，证据等级：`implementation intent exists but not rigorous / buggy`。
+
+### 运行上下文
+
+- 浏览器页面可访问、页面日期控件存在、会话已登录，来自 scene/inventory/reference 的联合描述，证据等级以 `code-confirmed`（元数据存在）和 `contract-defined`（具体语义）共同成立。
+- `report-history`、`local-report-service` 被声明为依赖，但 reference 同时强调历史报告不是主数据源、localhost 服务是下游依赖，证据等级：`code-confirmed` 与 `contract-defined`。
+
+### 依赖
+
+- `browser`、`fault-detail-query-source`、`local-report-service` 等依赖名称或整理项可直接在 scene 或 inventory 中定位，证据等级：`code-confirmed`。
+- `/a_js/YPTAPI.js`、`http://localhost:13313/ReportServices/*`、`faultDetailsExportXLSXS` 等更具体依赖来自 reference，证据等级：`contract-defined`。
+
+## 7. 输出结构
+
+当前输出结构是本场景最硬的直接证据。`collect_fault_details.js` 已直接定义：
+
+- `type: "report-artifact"`
+- `report_name: "fault-details-report"`
+- `period`
+- 主表 `columns` = `DETAIL_COLUMNS`
+- 主表 `rows` = `[]`
+- `sections[0].name = "summary-sheet"`
+- `sections[0].columns = SUMMARY_COLUMNS`
+- `sections[0].rows = []`
+- `status = "ok"`
+- `partial_reasons = []`
+
+以上全部属于 `code-confirmed`。
+
+但 `SKILL.md` 与 `data-quality.md` 还要求输出中体现 detail row count、summary row count、required column coverage、complete/partial status、missing columns、weak mappings、downstream failures 等诊断信息。除了 `status` 与 `partial_reasons` 字段壳子已经存在，其他诊断性内容并未在脚本中实现，证据等级：`implementation intent exists but not rigorous / buggy`。
+
+## 8. 下游动作证据表
+
+| 下游动作 | 当前证据 | 证据等级 | 严谨结论 |
+| --- | --- | --- | --- |
+| 生成 `report-artifact` 返回给上游 | `collect_fault_details.js` 直接返回对象 | `code-confirmed` | 已有稳定的 artifact 结构桩实现，但当前返回为空数据模板。 |
+| 明细列顺序标准化 | `DETAIL_COLUMNS` 明确定义 | `code-confirmed` | 只能确认列 schema 被定义，不能确认真实行数据已按此顺序完成映射。 |
+| `summary-sheet` 分区存在 | `sections` 中直接构造 `summary-sheet` | `code-confirmed` | 只能确认 section 模板存在，不能确认真实汇总派生逻辑已实现。 |
+| 页面采集故障明细行 | 只在 `SKILL.md` / `collection-flow.md` 中描述 | `contract-defined` | 存在明确目标流程，但当前 packaged script 未直接证明已实现。 |
+| 汇总派生 | 只在 `SKILL.md` / `collection-flow.md` / `data-quality.md` 中描述 | `contract-defined` | 有契约与质量要求，但没有脚本级派生代码证据。 |
+| 导出 Excel | scene 依赖与 reference 提到 localhost export service | `contract-defined` | 这是下游依赖定义，不等于本 skill 当前已实际执行导出。 |
+| 写报告日志 | scene 依赖 `report-history`，reference 提到 report-log | `contract-defined` | 只能确认体系中有该下游概念，当前脚本未直接实现日志写入。 |
+| partial / empty / blocked 状态细分 | skill/reference 有规则，脚本固定 `status: "ok"` | `implementation intent exists but not rigorous / buggy` | 状态模型意图存在，但 packaged script 目前未严格承载这些分支。 |
+
+## 9. 当前代码疑点 / 不严谨点
+
+1. `period` 与 `startTime/endTime` 的建模不一致。scene 与脚本只保留 `period`，reference 却明确要求读取开始/结束时间；这会让 command-center 难以判断标准输入究竟是一段字符串还是两个独立时间字段，证据等级：`implementation intent exists but not rigorous / buggy`。
+2. 脚本把 `status` 固定为 `"ok"`，但 reference 与 `SKILL.md` 明确区分 success / partial / empty / blocked；当前实现无法承载这些语义，证据等级：`code-confirmed` 对现状成立，而“应支持细分状态”属于 `contract-defined`。
+3. `partial_reasons` 虽存在字段，但脚本没有任何填充逻辑，只能算 schema 占位，证据等级：`code-confirmed`。
+4. `DETAIL_COLUMNS` 与 `SUMMARY_COLUMNS` 已定义，但没有任何从页面数据到列值的映射代码；“字段归一化能力已落地”不能成立，证据等级最多为 `implementation intent exists but not rigorous / buggy`。
+5. 下游导出与日志在参考资料中存在，但当前 skill 脚本并未调用相关服务，因此“报表可直接生成 Excel”不能写成当前代码事实，证据等级：`no direct evidence / candidate only`（就 packaged script 内实际执行而言）。
+
+## 10. 对 command-center 标准配置的修订建议
+
+1. 将本场景输入从单一 `period` 修订为更严谨的双层表达：
+   - 对外统一层可保留 `period` 便于路由；
+   - 执行层建议显式展开 `startTime` / `endTime`。
+   其中“需要展开”的结论来自 scene 与 reference 的冲突修正，证据等级：`implementation intent exists but not rigorous / buggy`。
+2. 在标准配置里把“artifact schema 已明确、live collector 未证实”作为单独字段或备注保留，避免 command-center 误把 schema stub 当成已实现采集器，证据等级：`code-confirmed`。
+3. 将 `summary-sheet` 标记为 `section template confirmed`，而不是 `summary derivation implemented`。前者是 `code-confirmed`，后者当前没有同等强度证据。
+4. 状态模型建议分成两层：
+   - `declared_status_model`: success / partial / empty / blocked，来源于 skill/reference，证据等级：`contract-defined`；
+   - `implemented_status_behavior`: 当前仅看到固定 `ok` 成功壳，证据等级：`code-confirmed`。
+5. 对下游动作增加 `evidence_note`，明确 report-export / report-log 目前主要来自场景与参考定义，不是当前 packaged script 已证实行为。
+
+## 11. 最终严谨结论
+
+关于 `fault-details-report`，当前最可靠的结论是：仓库已经具备一个明确的报表 artifact 模板实现，能够稳定返回故障明细主表列定义、`summary-sheet` 汇总分区模板、空结果数组以及基础状态字段，证据等级：`code-confirmed`。
+
+但如果把结论提升为“已经实现真实浏览器故障明细采集、列归一化、汇总派生、导出与日志闭环”，则证据并不充分。相关行为主要存在于 `SKILL.md`、`references/collection-flow.md`、`references/data-quality.md` 与 scene 元数据中，能够证明的是目标流程与契约要求，而不是当前 packaged script 已严格完成这些逻辑。因此，本场景目前应被描述为“artifact schema / section template 定义强，live browser collection 行为证据弱”的 staged report scene，而不能被描述为已严谨落地的实时采集器。
--- a/docs/superpowers/specs/2026-04-08-jiayuguan-meter-outage-operation-analysis.md
+++ b/docs/superpowers/specs/2026-04-08-jiayuguan-meter-outage-operation-analysis.md
@@ -0,0 +1,225 @@
+# 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。
--- a/docs/superpowers/specs/2026-04-08-jinchang-business-environment-weekly-report-operation-analysis.md
+++ b/docs/superpowers/specs/2026-04-08-jinchang-business-environment-weekly-report-operation-analysis.md
@@ -0,0 +1,143 @@
+# jinchang-business-environment-weekly-report 操作分析
+
+## 1. 场景概述
+
+`jinchang-business-environment-weekly-report` 对应“国网金昌供电公司营商环境周例会报告”场景，目标是采集多来源指标并组装为分区结构化周报。根据 `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\scenes\jinchang-business-environment-weekly-report\scene.json`、`D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\jinchang-business-environment-weekly-report\SKILL.md` 与 `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\jinchang-business-environment-weekly-report\scripts\collect_business_environment_metrics.js`，当前已被代码直接证实的是：打包脚本定义了四个 section template、空主表、`period` 字段、`status: "ok"` 与 `partial_reasons: []`，证据等级：`code-confirmed`。
+
+同时必须明确说明：当前 packaged script 更强地定义了 artifact schema / section template，而没有同等强度地定义真实浏览器采集、跨系统查询、period 对齐或导出执行逻辑。换言之，本场景当前更像“结构化周报模板脚本”，而不是“已被脚本严格实现的多源实时采集器”，证据等级：`code-confirmed`。
+
+## 2. 证据来源
+
+本分析统一只使用四个证据等级标签：`code-confirmed`、`contract-defined`、`implementation intent exists but not rigorous / buggy`、`no direct evidence / candidate only`。凡涉及脚本直接定义的 schema / section template，标为 `code-confirmed`；凡涉及将真实采集结果映射进这些结构的运行语义，如脚本未直接实现，则不高于 `contract-defined`。
+
+1. `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\jinchang-business-environment-weekly-report\scripts\collect_business_environment_metrics.js`
+   - 直接定义四个 section template：`abnormal-transformer-monitoring`、`power-outage-monitoring`、`work-order-acceptance`、`dispatch-summary`，并返回空 artifact，证据等级：`code-confirmed`。
+2. `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\jinchang-business-environment-weekly-report\SKILL.md`
+   - 说明应读取周范围、校验会话、收集多个 metric group、映射到 report sections、必要时标记 partial，并在输出里返回 `region`、`period`、缺失 section、周期对齐问题等。它主要定义目标契约与运行意图，证据等级以 `contract-defined` 和 `implementation intent exists but not rigorous / buggy` 为主。
+3. `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\scenes\jinchang-business-environment-weekly-report\scene.json`
+   - 声明场景输入为 `period`，依赖包括 `browser`、`multi-source`、`local-report-service`，动作包括 `query` / `collect-report` / `aggregate-sections`，证据等级：`code-confirmed`。
+4. `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\jinchang-business-environment-weekly-report\references\collection-flow.md`
+   - 描述周范围读取、跨系统会话校验、多指标组采集、section 装配与下游导出关系，证据等级：`contract-defined`。
+5. `D:\data\ideaSpace\rust\sgClaw\claw\claw\skills\skill_staging\skills\jinchang-business-environment-weekly-report\references\data-quality.md`
+   - 描述完整结果、partial 规则、弱点区域与 empty/failure 区分，证据等级：`contract-defined`。
+6. `D:\data\ideaSpace\rust\sgClaw\claw-new\docs\superpowers\specs\2026-04-08-command-center-virtual-employee-inventory.json`
+   - 归纳出 workflow、key_fields、status_model 等 command-center 视图；它能帮助识别当前整理结果，但不应被当成比原始 scene/skill/script 更强的实现证据，证据等级：`no direct evidence / candidate only`（仅限 inventory 不能单独证明 packaged script 已实现的部分）。
+
+## 3. 实际入口与运行边界
+
+实际入口在 `scene.json` 中已固定：场景页面入口为 `index.html`，技能调用为 `jinchang-business-environment-weekly-report.collect_business_environment_metrics`，输出 artifact 类型为 `report-artifact`，这些都属于 `code-confirmed`。
+
+运行边界方面，当前仓库能确认的内容是：
+
+- 对外输入名为 `period`，证据等级：`code-confirmed`。
+- 需要浏览器页面、多源系统访问与本地报告服务，证据等级：`code-confirmed`。
+- 参考资料要求按周范围收集多个指标组并组装 section，证据等级：`contract-defined`。
+
+但“真实 collector 已在 packaged script 中实现多源访问、登录态校验、周期一致性检查”这一说法并不成立。当前脚本只返回空 section 模板，因而其可直接证明的运行边界仍是 schema stub；多源采集与组装仅体现为明确实现意图，而非已严格落地逻辑，证据等级：`implementation intent exists but not rigorous / buggy`。
+
+## 4. 代码已证实的实际操作流程
+
+当前代码能严格确认的实际操作流程如下：
+
+1. 调用 `collectBusinessEnvironmentMetrics(input)`。
+2. 读取 `input.period || ""` 写入 artifact 的 `period`。
+3. 构造空主表：`columns: []`、`rows: []`。
+4. 基于 `SECTION_TEMPLATES` 复制出 4 个 section，并确保每个 section 的 `rows: []`。
+5. 返回 `type: "report-artifact"`、`report_name`、`status: "ok"`、`partial_reasons: []`。
+
+这些步骤均可在 `collect_business_environment_metrics.js` 中直接定位，证据等级：`code-confirmed`。
+
+以下步骤虽然在 `SKILL.md` 与 reference 中多次出现，但并未被脚本直接实现：读取页面周范围、校验多源 token/session、采集变压器监测/停电监测/工单受理/调度总结等真实数据、检查 period alignment、生成最终文档或导出结果。这些内容不能写成“代码已证实的实际流程”，最多只能分别标记为 `contract-defined` 或 `implementation intent exists but not rigorous / buggy`。
+
+## 5. 标准化抽象流程
+
+若做 command-center 的标准化抽象，本场景可整理为：
+
+1. 接收周报任务输入。
+2. 解析页面周范围并绑定会话上下文。
+3. 访问多个业务来源，按指标组采集数据。
+4. 按四类 section 模板/列结构承载结果。
+5. 形成统一 `report-artifact`。
+6. 视情况执行导出/日志等下游动作。
+
+其中第 4 步仅“四类 section 名称与列结构存在”是 `code-confirmed`；“真实采集结果已被映射进四类 section”仍只属于 `contract-defined` 的流程约定。第 2、3、6 步主要来自 skill/reference 的运行说明，证据等级应为 `contract-defined`。如果把这些步骤进一步写成“当前 packaged script 已可靠执行”，就会过度推断，证据等级只能降为 `implementation intent exists but not rigorous / buggy`。
+
+## 6. 输入、上下文与依赖
+
+### 输入
+
+- `period` 是 scene 与脚本已共同声明的业务输入，证据等级：`code-confirmed`。
+- `SKILL.md` 还要求输出中包含 `region`，但 scene 输入与 script 返回结构都未显式声明 `region` 字段，证据等级：`implementation intent exists but not rigorous / buggy`。
+
+### 运行上下文
+
+- `session`、多源系统可访问性、缓存 token 可用性等在 scene/reference 中被描述，scene 元数据层面的存在是 `code-confirmed`，更具体的业务语义是 `contract-defined`。
+- 页面历史报告区、执行日志区被 reference 提到，但被明确描述为下游历史/辅助区域，而非主数据源，证据等级：`contract-defined`。
+
+### 依赖
+
+- `browser`、`multi-source`、`local-report-service` 可直接在 scene 中定位，证据等级：`code-confirmed`。
+- `/a_js/YPTAPI.js`、`http://localhost:13313/ReportServices/*`、导出或 surface 服务来自 reference，证据等级：`contract-defined`。
+
+## 7. 输出结构
+
+当前脚本直接证实的输出结构包括：
+
+- `type: "report-artifact"`
+- `report_name: "jinchang-business-environment-weekly-report"`
+- `period`
+- `columns: []`
+- `rows: []`
+- `sections` 包含 4 个固定模板
+- `status: "ok"`
+- `partial_reasons: []`
+
+这些均属于 `code-confirmed`。
+
+四个固定 section template 分别为：
+
+1. `abnormal-transformer-monitoring`
+2. `power-outage-monitoring`
+3. `work-order-acceptance`
+4. `dispatch-summary`
+
+它们的列结构也都在脚本中已明确定义，证据等级：`code-confirmed`。
+
+但 `SKILL.md` 输出部分提到应返回 `region`、missing sections、period alignment issues、downstream export/logging failures。除 `period` 与空 `partial_reasons` 字段外，其余诊断信息都没有在脚本中被明确建模。尤其是 `region` 出现在输出文案中，却没有进入 artifact schema，这是一处场景特定的不一致点，证据等级：`implementation intent exists but not rigorous / buggy`。
+
+## 8. 下游动作证据表
+
+| 下游动作 | 当前证据 | 证据等级 | 严谨结论 |
+| --- | --- | --- | --- |
+| 返回分区化 `report-artifact` | `collect_business_environment_metrics.js` 直接返回对象 | `code-confirmed` | 已有稳定 artifact 壳，但内容为空模板。 |
+| 四类 section 模板存在 | 脚本直接定义 `SECTION_TEMPLATES` | `code-confirmed` | 只能确认 section schema 已确定，不能确认 section 数据采集已实现。 |
+| 多源指标采集 | 只在 `SKILL.md` / `collection-flow.md` 中描述 | `contract-defined` | 契约上明确需要多源采集，但当前 packaged script 未直接证明。 |
+| 周期一致性判断 | `SKILL.md` / `data-quality.md` 提到 period alignment | `contract-defined` | 存在质量要求，但脚本没有 period alignment 逻辑。 |
+| 导出周报文档 | reference 提到 localhost export/surface services | `contract-defined` | 属于下游依赖定义，不等于当前 skill 已执行文档导出。 |
+| 报告日志写入 | `SKILL.md` / reference 提到 report-log | `contract-defined` | 只能确认有该下游概念，当前脚本没有调用证据。 |
+| `partial` 结果建模 | 脚本保留 `partial_reasons`，reference 定义 partial 语义 | `implementation intent exists but not rigorous / buggy` | 字段壳子存在，但没有真实 partial 分支。 |
+| `region` 输出 | 只在 `SKILL.md` 输出说明中出现 | `implementation intent exists but not rigorous / buggy` | 表达上存在地区语义，但未进入 scene 输入或 artifact schema。 |
+
+## 9. 当前代码疑点 / 不严谨点
+
+1. `region` 出现在 `SKILL.md` 的输出项中，但 scene.json 与脚本 schema 都没有显式 `region` 字段；这意味着“金昌”可能只是场景名称隐含语义，而非可追踪输出字段，证据等级：`implementation intent exists but not rigorous / buggy`。
+2. 脚本固定返回空 `columns` 与空 `rows`，说明主表并不是核心结构，真正的核心是 4 个 section template；如果 command-center 仍把它当通用主表型报表，容易误建模，证据等级：`code-confirmed`。
+3. `status` 固定为 `"ok"`，与 skill/reference 所要求的 partial / empty / blocked 区分不一致，证据等级：`code-confirmed` 对现状成立，而目标状态模型仅为 `contract-defined`。
+4. 参考资料强调多源系统会话与 token 缓存，但脚本完全没有这些依赖的执行路径，因此“多源采集能力已落地”不能被提升为当前代码事实，证据等级：`implementation intent exists but not rigorous / buggy`。
+5. 导出与报告历史区域在 reference 中存在，但未被脚本直接接入；若在 command-center 中直接把它配置为“可导出 Word/Excel”现状，将属于过度推断，证据等级：`no direct evidence / candidate only`（就 packaged script 执行层而言）。
+
+## 10. 对 command-center 标准配置的修订建议
+
+1. 本场景应把核心输出建模为 `section-based report artifact`，而不是普通二维表。原因是脚本对四个 section template 的定义明显强于对主表的定义，证据等级：`code-confirmed`。
+2. 在标准配置中补充 `region_semantics` 或 `fixed_region` 字段，明确“金昌”究竟只是场景命名，还是应成为可展示/可审计输出的一部分。目前这是未闭合问题，证据等级：`implementation intent exists but not rigorous / buggy`。
+3. 状态模型建议拆分：
+   - 契约层声明 success / partial / empty / blocked，证据等级：`contract-defined`；
+   - 实现层当前只有固定 `ok` artifact stub，证据等级：`code-confirmed`。
+4. 给配置增加 `collection_evidence` 备注，明确当前 packaged script 更偏向 section schema 模板，而不是 live browser collector，避免后续调度器把它误当已完成的实时采集技能。
+5. 对 `downstream_effects` 建议增加 `implemented: false / not-directly-proven` 之类标记，以区分“场景上需要导出”与“脚本里已执行导出”。
+
+## 11. 最终严谨结论
+
+关于 `jinchang-business-environment-weekly-report`，当前最可靠的现状判断是：仓库已经存在一个四分区结构化周报 artifact 模板，四个 section 的名称与列 schema 已由 packaged script 直接定义，证据等级：`code-confirmed`。
+
+但“已经实现真实浏览器多源采集、周期一致性校验、section 数据组装、最终导出与日志闭环”这一更强表述没有被脚本直接证明。相关行为主要由 `SKILL.md`、`collection-flow.md`、`data-quality.md` 与 scene 元数据定义目标流程和质量要求，因此应把它理解为“有明确契约和实现意图，但当前 packaged script 主要还是 schema/section stub”。此外，`region` 在输出话术中出现、却未进入 artifact schema，是本场景当前最需要在 command-center 标准配置中澄清的不严谨点。
--- a/docs/多核浏览器管道API接口文档.docx
+++ b/docs/多核浏览器管道API接口文档.docx