决策视图 (decision-draw) — 捆绑决策的全局概览与整体签核 是做什么的？
当有五个或十个决策待定时，人们很容易陷入孤立选项的细节中，从而忽视正在形成的系统全貌。决策视图不描述替代方案；它描绘的是工作的整体：一旦所有推荐方案就位，各系统如何协同运作？用户要么整体签核这个视图，要么提供有针对性的反馈。
使用时机
- 多个相互依赖的决策（来自决策简报或决策简报文档）不应通过繁琐的逐个问题清单来逐一审核。
- 用户希望在批准之前，看到各组件在实际日常实践中如何交互。
- 通过依赖关系图（决策路径）识别出的一组紧密耦合的决策，可以作为一个功能单元整体签核。
- 触发词：
/decision-draw、“如果我们同意所有方案，整体看起来是什么样的”、“绘制大图”、“整体决策概念”、“决策绘制”、“实施后各系统如何协同工作”、“整体签核视图”。 - 不要使用：
决策系列中的界限
| 技能 | 用户体验与焦点 | 对选项的立场 | 签核模式 |
|---|---|---|---|
decision-briefing | 分解为单个项目 | 显示所有选项 A/B/C/D | 字母代码 (1A 2C 3B) |
decision-path | 结构化因果关系 | 在图中评估选项 | 终端诊断 (ASCII) |
decision-draw | 连贯的目标视图（捆绑相互依赖的决策） | 仅描述推荐的方案（替代方案已链接） | 整体签核或修正语句 |
decision-shot | 结构化离散区块（用于单个问题或紧密分组） | 显示带有2-4点利弊的选项 | 行政决策 / 单独审查 |
decide | 逐步解决单个问题 | 评估矩阵（标准） | 分析性推荐 |
核心规则：
decision-draw仅描述推荐的方案。被放弃的替代方案并未消失 — 它们记录在决策简报、决策快照或链接的工单中，并在标题表中引用。缺少此链接的视图会剥夺用户的选择权，而不是简化它。
强制结构（七个部分）
一个完整的 decision-draw 严格遵循以下七部分布局：
1. 捆绑与范围
捆绑中所有项目的表格摘要：
- 缩写/ID（例如
BH-A、MD-A、CF-A） - 工单引用
- 项目的简短标题
- 假设的推荐方案（此全局视图的前提）
decision-avatar信心等级（🟢 已记录、🟡 权衡、🔴 需要升级）- 完整分析/替代方案的链接
2. 概念
以连贯的散文形式描述的目标状态：
- 当所有推荐方案按计划执行时，会产生什么样的系统景观或工作流程？
- 没有并排的选项比较，没有虚拟语气的模糊处理（“也可以……”）。
- 清晰、自信的陈述语气：这就是系统在其目标状态下的运作方式。
3. 互动
该技能的核心功能：
- 已确定的组件在实施后如何实际协同工作？
- 沿着具体的端到端操作流程展开（例如：“工单到达 → 代理启动 → 后端分配 → 部署到主机”），而不是一个静态的组件列表。
- 阐明数据流、接口和运营职责。
4. 实施
具体的逐步推出序列：
- 在实践中，一步步发生什么？
- 直接从决策路径继承执行序列和依赖逻辑。
- 独立的工作流应诚实地表示为并行轨道（不要发明人为的因果链；一个捆绑可能由多个并行轨道组成）。只有在存在实质性依赖关系或截止日期时，才断言顺序排序。
- 突出显示关卡、迁移脚本和验证检查。
5. 此视图未涵盖的内容
针对错误完整性的边界防御：
- 哪些次要问题、未解决事项或🔴信心等级被故意排除在外？
- 与相邻系统的边界线在哪里？
- 一个隐藏其边缘的视图会产生错误的安全感。
6. 签核
用户交互：
- 用户整体审查该视图。
- 响应选项1：明确的整体签核（“看起来不错”、“批准”、“按提议实施所有内容”）。只有在这种情况下，所有捆绑项目才被标记为已决定。
- 响应选项2：自然语言的有针对性修正（“对BH-A更喜欢较小的方案”、“MD-A不要自动重启”、“保持VM-A不变”）。触发拆解为离散决策；所有未修正的项目保持开放状态。
7. 回写
将用户反馈系统地翻译为单个分类账条目：
- 无自动共同记录： 未更改的项目仅在明确的整体签核时才被记录。部分修正不是整体批准！
- 修正时的隔离： 如果用户提交修正，它会被拆解为单个决策；捆绑中的所有其他项目严格保持开放状态（在源工单/分类账中），直到用户接受调整后的视图整体或单独确认剩余项目。
- 强制回写表： 每个部分反馈都会生成一个结构化的评估表，包含四列：
- 原始修正：用户原话。
- 受影响的关键项：哪些捆绑ID被更改（包括一个陈述影响多个决策的多重命中）。
- 多米诺状态：决策路径中的哪些依赖节点或下游假设会崩溃或需要重新评估。
- 未解决的歧义：修正允许多种解释需要澄清才能记录的地方。
- 处理多重命中： 一个用户陈述可以同时更改多个决策。回写必须解开这种耦合并一起捕获所有受影响的关键项。
- 唯写路径经由第四阶段：
decision-draw没有原生的写入路径到工单或登记册。分类账更新仅通过决策简报第四阶段的标准协议进行（记录并持久化到DECIDED-AND-DONE.md或TO-DECIDE-USER.txt）。
示例（试点数据集：票务大师 2026-09-13 — BACH 与系统集群）
来自 2026-09-13 票务大师决策简报的真实捆绑：BH-A、MD-A、CF-A、VM-A、PD-A。
# 决策视图：BACH 核心集群与运营完整性
## 1. 捆绑与范围
| 关键项 | 工单/来源 | 主题 | 假设推荐 | 信心 | 替代方案与详情 |
|---|---|---|---|---|---|
| `BH-A` | `T-20260913-896336887` | 模型后端 = 心脏 | 1A / 2A / 3A / 4B / 5A / 6A | 🟢 | `docs/MODELL-BACKEND-KONZEPT_2026-09-13.md` |
| `MD-A` | `T-20260913-799464688` | Mac 部署与重启 | A1 + 脚本（24/7 仅报告） | 🟢 | 工单 `T-20260913-799464688.txt` |
| `CF-A` | `T-20260913-947070291` | 跨主机配置目标 | 1C（已论证）/ 2B（依赖主机）/ 3B（高） | 🟢 / 🟡 | 工单 `T-20260913-947070291.<HOST>.txt` |
| `VM-A` | `T-20260906-496406575` | VersicherungsManager 时区 | A（应用级设置，类似 routinika） | 🟢 | 工单 `T-20260906-496406575.<HOST>.txt` |
| `PD-A` | `T-20260913-609930207` | USMC 页面可见性 | A（将声明对齐到公开，保留现状） | 🟢 | 工单 `T-20260913-609930207.txt` |
*注：所有被放弃的替代方案（例如 BH-A E5=B ocean-heart、MD-A A2 完整写入密钥、VM-A B 按配置文件分区）仍记录在票务大师决策简报中。*
---
## 2. 概念
我们建立一个干净、解耦的多主机架构，其中模型后端作为一个名为 `agents-heart` 的独立核心模块运行。角色、权限和预算在关系型 SQLite 数据库中清晰维护，而模型路由决策分两个阶段发生：BACH 构建领域限定的候选集，然后 clutch 在该集合内选择成本和能力最优的模型。
在 Mac Studio 上，24/7 后台服务使用只读部署密钥安全可靠地运行；代码更新自动拉取，正在运行的 24/7 服务会收到温和通知而不是被强制终止。配置可能在性能要求时保持主机特定，而应用级设置（如 VersicherungsManager 中遵循经过验证的 routinika 模式的时区）被确定性地硬编码。USMC 仍然是规范的公共记忆门面，并保留其在公共网站上的位置。
---
## 3. 互动
这五个项目并不形成一个串行因果链；相反，它们代表了模块化、解耦的日常运营完整性支柱，在系统中以并行方式互锁：
- **核心架构与模型路由 (`BH-A`)：** `agents-heart` 模块解耦了模型分配。当任务到达时，BACH 确定领域限定的候选集，然后 clutch 选择成本和容量最优的模型。
- **主机配置与部署完整性 (`CF-A`、`MD-A`)：** 虽然笔记本电脑和工作站应用一致的推理努力（`CF-A`；依赖主机的模型保持透明），但 Mac Studio 在验证过的设置下运行持久后台进程。对于更新，Mac 通过只读部署密钥拉取代码（`MD-A`）；GUI 服务器重启，而长时间运行的后台服务温和地通知仪表板需要更新。
- **领域持久化与截止日期 (`VM-A`)：** 诸如 VersicherungsManager 之类的应用，基于应用级 `settings` 表（遵循 routinika 模式）持久化截止日期。计算和截止日期监视器在所有配置文件上，基于相同的 IANA 时区确定性地运行。
- **公开呈现 (`PD-A`)：** 夜间站点构建器验证仓库状态。USMC 在其修正后的 `public` 声明下被干净地发布，在安全门中触发零警报。
---
## 4. 实施
由于源数据集在依赖关系图（[决策路径](../decision-path/SKILL.md)）中并未证实这五个项目之间存在串行链，因此发布被诚实地分为四个独立的并行工作流（方法 A：并行轨道而非人为因果关系）。顺序排序仅适用于存在外部截止日期或内部步骤的情况：
- **轨道 A（时间关键 — 截止日期 2026-09-14）：**
1. 将 USMC 元数据对齐到 `public`（`PD-A`）；放弃草稿 PR #2。由于夜间构建器运行，延迟不可容忍，但此步骤在技术上完全独立于所有其他轨道。
- **轨道 B（主机配置与 Mac 部署 — 可并行化）：**
1. B1：在 `.SYNC` 中编码配置目标（`CF-A`），将两个主机的推理努力同步到 `high`。
2. B2（独立于 B1）：在 Mac Studio 上安装只读部署密钥并设置拉取与报告自动化脚本（`MD-A`）。
- **轨道 C（领域数据库 — 可并行化）：**
1. 在 VersicherungsManager 中实现应用级 `settings` 表迁移，遵循 routinika 模式（`VM-A`），为后续的发布者开发建立干净的基线。
- **轨道 D（架构提取 — 内部多阶段计划）：**
1. D1：在 `agents-heart` 中设置角色和权限的 SQLite 模式（`BH-A` E1）。
2. D2：将后端目录提取为 Python 模块（`BH-A` E3）并绑定 clutch 分配接合点（`BH-A` E2）。
3. D3：提取并绑定 `agents-heart` 模块（`BH-A` E5、E6）。
---
## 5. 此视图未涵盖的内容
- **任务竞争条件：** 允许重复任务声明的并发错误正在一个专门的热修复工单中处理，不在本签核范围内。
- **驾驶舱前端：** 监控驾驶舱（`BH-A` E4）故意推迟，直到后端产生实时运营遥测数据。
- **发布公共仓库：** 合并和暂存代码不会自动使私有仓库公开；最终的可见性切换保留给用户。
---
## 6. 签核
您可以整体签核此系统集群，或提供自然语言调整：
- **明确的整体签核：** “看起来不错，完全按提议实施。”（只有此操作才会触发所有项目的记录）。
- **修正示例：**
- *“Mac 不需要主机特定处理：MD-A 需要完整写入密钥 (A2) 以直接推送，CF-A 应将所有配置严格对齐到工作站（组 1=A，2=A）。”* （多重命中）
- *“对于 BH-A E5，将其命名为 ocean-heart 而不是 agents-heart。”*
- *“暂时推迟 VM-A；发布者可以等待。”*
---
## 7. 回写
当概念被批准或修改时，该技能将反馈翻译为分类账条目：
### 案例 A：明确的整体签核
当用户明确批准整体视图时（例如*“看起来不错，完全按提议实施”*）：
- 所有五个项目（`BH-A: 1A/2A/3A/4B/5A/6A`、`MD-A: A1`、`CF-A: 1C/2B/3B`、`VM-A: A`、`PD-A: A`）作为 DECIDED 传递给[决策简报](../decision-briefing/SKILL.md)第四阶段。
- 第四阶段执行分类账写入…
（条款因翻译长度而截断）
### 案例 B：部分修正
回写表：修正拆解
| 原始修正 | 受影响的关键项 | 多米诺状态 | 未解决的歧义 |
|---|---|---|---|
| "No host-specific special handling for the Mac: MD-A needs full write keys (A2) for direct pushing, and CF-A should strictly align all configurations to the workstation." | MD-A → A2 (was A1); CF-A → 1=2A 2=2A (was 1C/2B) | MD-A A2 → Full write key invalidates read-only assumption in Track B; CF-A 1=2A → Host-dep. config removed → B1 can proceed without host branching. | Has the user also changed CF-A 3? Sentence only mentions CF-A 1 and 2 → CF-A 3 remains at 3B until clarified. |
### 案例 C：整体拒绝并返回简报
如果用户的修正如此广泛，以至于实际上推翻了捆绑的整体前提，则概念将发送回决策简报：
- 项目保持 OPEN。
- 决策简报开始新的回合 R+1，将用户的反馈作为新的约束条件。
---
## 边界总结
| 技能 | `decision-draw` 的边界 |
|---|---|
| `decision-briefing` | 不替换简报；简报决定*选项*；draw 决定*全局视图* |
| `decision-path` | 路径提供依赖关系；draw 从路径继承序列以构建*实施轨道* |
| `decision-shot` | 快照分析单个问题（或紧密分组）；draw 捆绑*多个*相互依赖的决策 |
| `decide` | 决定（decide）逐步解决一个政策问题；draw 假设推荐方案已就位 |
---
*本文档是 decision-draw 技能的完整说明。有关决策系列其余部分的更多信息，请参阅相关技能的文档。*