decision-path — 待处理决策的 ASCII 依赖关系图 是做什么的？
决策并非发生在真空中。在孤立看来合理的事情，常常会阻塞后续工作、预设未构建的前提条件，或绕过既定的安全门。decision-path 将因果关系、执行顺序和矛盾性透明地呈现在终端上。
使用时机
- 已有一份待处理决策的清单（来自 decision-briefing 阶段 1、会话上下文或票务主决策简报），需要结构化。
- 您需要确定哪些决策可以立即执行（根节点），哪些依赖于先决条件或外部阻塞因素。
- 您需要一个概览，了解哪些建议是和谐一致的，以及哪两个建议在逻辑上或操作上存在冲突。
- 触发词：
/decision-path、"哪些决策相互依赖"、"决策依赖关系图"、"可视化决策路径"、"ASCII 决策树"、"决策之间的矛盾"、"检查因果依赖"。 - 不要用于：
- 首先发现和盘点待解决的问题——那是 decision-briefing 阶段 1 的职责。
- 将推荐的选择打包成一个连贯的概念以供批准——那是 decision-draw 的职责。
- 紧凑的五部分块，包含选项和每个选项的正反论据——那是 decision-shot 的职责。
- 使用方法论（加权评分、情景分析）系统地评估单一复杂决策——那是 decide 的职责。
在决策家族中的边界
| 技能 | 角色 | 输入 | 输出 |
|---|---|---|---|
decide | 方法论地结构 单个 决策 | 标准、选项 | 评分矩阵、单个决策 |
decision-briefing | 将多个 待处理决策分解为带有选项的独立问题 | 待处理点列表 | 编号的 A/B/C/D 简报、粗略依赖标记、批量预约 |
decision-path | 验证并可视化 多个决策间的因果关系和矛盾 | 来自简报/注册表的粗略标记 | 包含 5 个节点评估和边状态的 ASCII 依赖关系图 |
decision-draw | 将建议打包成一个连贯的整体 以供批准 | 来自 decision-path 的打包 | 概念、相互作用（仅推荐变体）、回传 |
decision-shot | 将 完成的分析 压缩成其执行摘要（1 个决策或紧密打包） | 1 个已分析的问题或组 | 五部分简短表格，包含选项、正反论据和完整分析链接 |
decision-avatar | 建模用户偏好和行为历史 | 上下文、过去的选择 | 置信度评分 🟢 / 🟡 / 🔴 |
与 decision-briefing 的契约和职责
decision-briefing 阶段 1 已经在收录期间推导出粗略的依赖关系和执行顺序（例如，来自诸如 "此后自动:"、阻塞点或票证引用等信号）。decision-path 不会重复此推导，而是直接建立在以下这些粗略标记之上：
- decision-briefing 提供粗略标记： 它提供待处理项的原始清单和初始耦合线索。
- decision-path 验证、评估和可视化： 它根据已记录的事实验证信号，分离已确认和推测的边，为每个节点分配五个评估，并暴露门碰撞。
- 发现差异的反馈循环： 如果
decision-path发现简报中缺少或错误表示的依赖关系，它永远不会默默地吸收它，而是作为更正说明明确报告回简报。
每个节点的五个评分（和边验证状态）
五个维度 [S E U Z W] 评估 节点（在其系统上下文中的待定或已确定决策）。边携带其语义关系类型（例如，解锁、阻塞、先决条件）和验证状态（已确认 vs. 推测）。
图中的每个节点显示一个紧凑的五元素评估字符串：
[S+ E:<Option> U<Direction><Confidence> Z+ W-]
-
合理性 (Sensible,
S) — 技术和架构的稳健性：S+: 解决方案稳健，解决了实际问题，避免了人为的复杂性。S~: 部分合理，但带来了维护或运营开销。S-: 错误的解决方案、表面文章或一个已知的死胡同（例如，在错误的杠杆点进行过滤）。
-
推荐性 (Recommended,
E) — 具体的、有证据支持的推荐行动：E:<Option>: 明确的选择（例如，E:A、E:B、E:resolve、E:Step1）。E-: 无法提出可操作的推荐（缺少事实或属于高层政策问题）。
-
用户典型性 (User-typical,
U) — 与用户过去习惯和规范化规则的一致性（通过decision-avatar）： 代码 方向（选项是否符合习惯？）和 验证置信度 分开编码：- 方向（U 后的第一个字符）：
+: 用户典型——匹配过去的决策、策略 (CLAUDE.md) 或明确偏好。~: 中立/开放——没有记录到主导的历史偏好。-: 非典型——偏离常规工作流程或既定习惯。
- 验证置信度（第二个字符）：
- 在 ASCII 图内部使用纯 ASCII：
!: 高/有依据（在散文体中：🟢 已记录）。~: 中/合理（在散文体中：🟡 权衡本质上属于用户）。?: 低/未经验证（在散文体中：🔴 政策问题，前所未有）。应上报而非猜测！
- 在 ASCII 图内部使用纯 ASCII：
- 示例：
U+!（典型且已记录），U+~（典型，但需要用户判断），U-!（已记录的非典型），U~?（开放，无先例 -> 上报）。
- 方向（U 后的第一个字符）：
-
一致性 (Coherent,
Z) — 与相邻节点的软架构和风格和谐：Z+: 与先决条件和下游决策无缝集成，形成无摩擦的整体。Z~: 轻微的样式摩擦或运营开销，但功能上可行。Z-: 系统相互作用中明显的摩擦（例如，配置膨胀、尴尬的耦合），但不违反硬性规则。
-
矛盾性 (Contradictory,
W) — 硬性矛盾和策略/门违反（最关键输出——警报！）：W-: 与其他推荐、策略和活跃的安全门无矛盾。W+: 硬碰撞 / 警报！ 使另一个推荐无效，违反既定策略 (CLAUDE.md、P-00x)，或绕过活跃的安全门。碰撞节点始终在CONTRADICTIONS部分中明确高亮显示，并附有根本原因和解决路径。
边类型和推导规则
依赖关系 严格从源文本推导，绝不发明。边携带其关系类型和验证状态：
| 源中的信号 | 边类型 | 符号 | 含义 |
|---|---|---|---|
| "此后自动:"、"解锁"、"启用" | 解锁 | +--> | 仅当源决策（已记录）处理后，目标决策才变得可操作 |
| "阻塞"、"阻止"、"安全门触发" | 阻塞 | => | 目标被阻塞，直到源被解决 |
| "需要"、"需要预先"、"先决条件" | 需要 | --> | 目标在逻辑上和时间上依赖于源 |
| "后续决策"、"下一步骤 2" | 顺序 | --> | 执行后的下游逻辑进展 |
| "被测量反驳"、"过时"、"被取代" | 无效化 | --X--> | 源的洞察使目标过时 |
| 共享 D-ID、票据 ID 或没有文本证据的相同子系统 | 推测 | ?--> | 合理的耦合但没有文档化的因果证据（未验证） |
关于未经验证边的规则： 当文本中不存在明确的因果陈述时，该边必须标记为推测 (
?-->)——绝不能作为已确认的事实。如果未记录任何关系，则节点保持未连接，并排显示。
ASCII 图格式指南
- 等宽字体和终端优化： 最大行宽 100 列。没有会换行并破坏终端布局的宽表格。
- 字符集和纯净性： 纯 ASCII。在图代码围栏内，不能出现 emoji（🟢🟡🔴）；置信度仅通过 ASCII 标记 (
!,~,?) 表示。 - 节点 ID： 仅使用现有标识符（
PD-A、MD-A、BH-A、VM-A、QR-A、CL-A、MO-A、D-001、732597768）。绝不发明合成 ID！如果项目缺少缩写，则使用其项目编号。后续的内部步骤表示为未编号的边注释(...)。 - 分层结构：
LEVEL 0 - independent: 根节点、未阻塞项、外部触发器。LEVEL 1 - depends on exactly one: 直接后续项。LEVEL 2 - depends on multiple / deep chain: 多依赖性或深度顺序节点。CONTRADICTIONS: 硬碰撞、门违反和冲突的推荐 (W+)。LEGEND: 每个图输出都必需。图中使用的每个结构字符（|、=Option、(...)、边箭头）都必须列出并在图例中解释。
- 可选的 Mermaid 围栏： 如果有用，可以附加一个
mermaid代码块；ASCII 图仍是主要的、权威的输出。
示例（试点数据集：票据主控 2026-09-13）
来自票据主控决策简报（732597768、MO-A、CL-A、QR-A、387521104、CL-B）的真实摘录：
====================================================================================================
DECISION-PATH: 依赖关系图 (试点 票据主控 2026-09-13)
====================================================================================================
0 级 - 独立节点（根决策和外部阻塞）
[732597768] 解决 GitHub 计费问题 [S+ E:resolve U+! Z+ W-]
| 解锁
+--> [MO-A] 发布第 2 波 [S+ E:A U+~ Z+ W-]
[CL-A] 离合器管理员合并 PR #6 和 PR #8 [S+ E:A U+! Z+ W-]
| 被阻塞于: [门 "1 个批准审查" (无法自我批准)]
--> (后续决策: 将分支保护设置为 0 或机器人)
[QR-A] 队列重命名 NTFS 连接点 (_TICKETS -> TICKETS) [S+ E:B U+! Z+ W-]
+--> [387521104] 夜间窗口运行 (已记录: 仅在 B 选项下)
[CL-B] 审查门试点: Mac 签名密钥 [S+ E:Step1 U+~ Z+ W-]
--> (后续步骤 2-4: 在密钥配置后建模自动化)
1 级 - 恰好依赖于一个前驱
[MO-A] 发布第 2 波 [S+ E:A U+~ Z+ W-]
| 需要: [732597768] (计费已解决，远程 CI 门再次激活)
| 需要: [门 PRIVATE.txt "绿色远程 CI"]
--> (后续步骤: 切换可见性仍是仅用户操作)
2 级 - 依赖于多个 / 深层链
[387521104] 在夜间窗口内自主迁移运行 [S+ E:B U+! Z+ W-]
| 需要: [QR-A]=B (已建立 NTFS 连接点)
| 需要: (通过在第二个主机上设置传输票据来设置连接点 -
| 票据编号未在简报中说明)
----------------------------------------------------------------------------------------------------
矛盾与门碰撞
---------------------------------------------------------------------------------------------------
[MO-A]=B X [门 PRIVATE.txt "绿色远程 CI"]
冲突: 选项 B 将仅基于本地测试发布第 2 波，
即使两个模块合同明确要求绿色远程 CI。
解决: 推荐 A 强制首先处理 [732597768]（计费），解决冲突。
[CL-A]=StatusQuo X [门 "1 个批准审查" (无法自我批准)]
冲突: master 分支需要 1 次审查，但唯一的存储库账户是 lukisch。
解决: 推荐 A（管理员合并）合法地打破了僵局。
----------------------------------------------------------------------------------------------------
图例和评分键
----------------------------------------------------------------------------------------------------
边和结构:
+--> 解锁 / 启用（来源中已记录的因果关系）
=> 阻塞 / 阻止（门或外部阻塞）
--> 需要 / 顺序（前提条件或后续步骤）
?--> 推测的依赖关系（合理的耦合，但未记录）
--X--> 无效化 / 取代（源的洞察使目标过时）
X 矛盾 / 碰撞（门或策略违反）
| 垂直层次线 / 属性映射
[ID] 决策节点（简报中的项目缩写或项目编号）
[Gate] 外部门 / 规则 / 合同 - 非决策节点
=Opt 节点的特定选项（例如 [MO-A]=B）
(...) 未编号的边注释 / 后续步骤（不发明合成 ID）
节点评估 [S E U Z W]:
S: 合理性 (+ 健全 / ~ 有条件 / - 不健全)
E: 推荐性 (A、B、C、resolve、Step1、- 无)
U: 用户典型性 (方向: + 典型 / ~ 中立 / - 非典型;
置信度: ! 有依据 / ~ 权衡 / ? 上报)
[! = 已记录 (散文体绿色), ~ = 用户权衡 (散文体黄色),
? = 未验证/上报 (散文体红色)]
Z: 一致性 (+ 和谐 / ~ 轻微摩擦 / - 架构断裂)
W: 矛盾性 (- 无冲突 / + 与门或策略硬碰撞)
====================================================================================================
decision-path 不做的事情
- 不做决策： 该技能提供结构透明度。决策权仍属于用户。
- 不发明选项： 该技能不进行头脑风暴新的替代方案或加权标准；这属于 decide 或 decision-briefing。
- 不创建紧凑的五部分块： 那是 decision-shot 的职责。
- 不打包概念以供批准： 那是 decision-draw 的职责。
- 不建模用户偏好： 那是 decision-avatar 的职责。
- 不在没有来源的情况下推导依赖关系： 如果简报中没有因果声明，节点将保持不连接。推测的边必须用
?-->标记。
逐步工作流程提示：
decision-briefing->decision-path->decision-draw（或decision-shot用于单一决策）。在处理所有依赖关系和矛盾之后，使用decision-draw将包提交给用户批准或提供紧凑摘要。