admin/claw
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: add command center analysis artifacts

Browse Source 
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>
This commit is contained in:
木炎
2026-04-09 10:43:09 +08:00
parent 57b9be733d
commit 630190e4d3
12 changed files with 3125 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

639
docs/superpowers/specs/2026-04-08-command-center-standard-config-structure.md Normal file
View File

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