claw/docs/superpowers/specs/2026-04-08-command-center-standard-config-structure.md

# 指挥中心虚拟员工标准配置清单建议结构

> 免责声明：本文件描述的是“未来可采用的规范化目标配置结构”，不是当前 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

只有在保持这些边界的前提下，这份“标准配置结构”才是严谨可持续的目标态提案，而不是再次把现状、推断和目标混写在一起。