决策帧写法修订:四维分析必须从业务角度写 —— 客户可感知的后果、选项真实代价表、行业类比、低摩擦裁决格式(维护者 2026-08-20 以 #10103 为范例裁定)

[os-warren]

维护者裁定(2026-08-20,原话:「四维分析应该从业务的角度写我才好判断,看这个例子。10103 帮我决策」),范例 = #10103 的决策分析全程:维护者对第一版(实现视角)的反应是「给我从业务的角度具体解释」,对业务版的反应是当场裁决「C」。一次追问 vs 当场可裁,就是这条修订的全部理由。

范围 —— os-decision-facets 决策帧的写法指引(治理面)

四条轴不变(项目长远合理性/实际业务拉动/防AI犯错/创业阶段不扩散,中文,PR #10010 既定)。修订的是写法要求,按 #10103 范例提炼:

1. 一句话问题:开头一句话说清冲突是什么,不带实现名词(范例:「organization_id = NULL 的行是什么?两个互相矛盾的答案都已落地」→ 业务版:「三家公司住一个数据库,管理员打开权限管理,三个页面全空」)。
2. 选项 × 真实代价表:每个选项一行「做什么 + 真实代价」,代价写客户可感知的后果(「这家客户的审批单出现在别家客户眼前」),不写机制名词;有实测的注明实测。
3. 业务含义直译:每个选项配一句「业务上 = …」,允许行业类比(范例:「像 Salesforce 每个 org 有自己的 profiles」)。
4. 四轴从业务立场论证:每轴的论据是客户/产品/事故后果,机制只作括号补充;「防 AI 犯错」轴写清出错时谁看到什么(响亮拒绝 vs 静默泄露)。
5. 推荐 + 回退 + 置信缺口:荐一项、给回退项、明说本分析看不见什么;结尾给低摩擦裁决格式(「回一个字母即可;或『C,但 X』= 自动落到 B」)。
6. 裁后执行段:「裁后我会怎么执行(你不用管)」—— 让维护者只裁方向不背执行。

边界

• 只约束 needs-user-decision 卡与决策箱讨论的四维分析;内部工具卡(dev 派发用)的四维照旧,不强加行业类比。
• ⛔ 帧的四份拷贝三文件强同步(check:skill-frame-sync),改指引文本必须保持结构同构,gate 会验。
• ⛔ SKILL.md 682/682 顶格:指引尽量落在帧的长文拷贝所在 references 文件;动主文须等量去重支付。
• 串行:pm-dispatch references 树上 分诊席读数成本三修:收班简报索引化(硬字符预算+自报判据)、互斥最小尾页读法、长线程状态读外包规则 —— pm-dispatch 治理面文本 #10108 在飞,本卡排其后派发,派发前重测行数与帧同步基线。
• 只适用新记录,不回改存量(skills(checklist-test): the documented QA-run title convention matches 0 of 23 real records #9617 先例:new-records-only)。

四维分析(按本卡自己的新规写)

• 实际业务拉动:范例实测 —— 实现视角的分析让维护者无法判断、追问一轮;业务视角当场裁决。决策箱现积压 4 件,每件省一轮追问就是净赚。
• 项目长远合理性:维护者是所有安全/契约面变更的唯一裁决人,分析写法就是裁决吞吐的瓶颈;把「翻译成业务」固化为席位义务而不是维护者的追问成本。
• 防 AI 犯错:模板逼着分析者回答「出错时客户看到什么」,这恰是 AI 最容易略过的一问(范例里 A 选项的真实代价正是靠这问暴露的)。
• 创业阶段不扩散:纯文本指引修订,轴不动、帧结构不动、gate 既有,一次落地全席受益。