维护者速读
事情：补录已签合同这个动作（F16「Backfill Executed Contract」），设计方案第 6 章写的是档案岗或法务都能用。实现出来只有档案岗（加管理员）能用，法务看不到这个按钮。
为什么：平台的 requiredPermissions 是 AND（要求全部持有），不是 OR。而档案岗和法务没有任何一项共同持有的能力，所以「或」这个语义在今天的平台上表达不出来。实现只好退而求其次，挂在 execute_contract 上（档案岗 + 管理员持有），法务因此丢了这一个按钮 —— 但法务的其他所有路径都不受影响。
发现于卡 09（#39 / PR #42，已合并）。当时没顺手改，因为三个补法里两个要动受管面或平台，不是开发能定的。
你要做的：回一个字母，A、B 或 C。
选项
|
做法 |
客户感知到的后果 |
| A（推荐） |
第 4 章新增一项能力（如 backfill_contract），同时授予档案岗与法务；动作改挂它 |
§06 F16 字面兑现，两个岗位都能补录。代价：改受管面 §04，多一项能力令牌 |
| B |
接受只有档案岗能补录，把 §06 F16 的「或法务」改掉 |
零新增。代价：收窄一项已声明的能力，法务补录要请档案岗代劳 |
| C |
向平台提「requiredPermissions 支持 OR 形式」的需求，等它落地 |
一次修好所有应用。代价：时间不可控，期间仍是 A 或 B 的现状 |
业务含义直译
A = 给「补录旧合同」这件事发一把专门的钥匙，法务和档案岗各拿一把；B = 承认补录是档案岗的活，法务要补录就走档案岗；C = 等平台把门锁改成「任一把钥匙都能开」。
四棱分析
os-decision-facets
① 项目长远合理性 — 偏 A。这是一个已声明但兑现不了的能力（§06 说「或」，系统做不到「或」），和这批卡反复在修的形状同一类。A 让实现追上声明；B 削声明去迁就实现，方向相反；C 是正确的长远形态但不在本仓手里。⚠️ 但 A 有一个代价要说破：为一个按钮新增一项能力令牌，是契约增生，和「缩小特例」的方向相反。
② 实际业务拉动 — 弱，且这一棱要求实测。判据是「今天谁撞上」。答案是：没有人，因为这个动作今天刚随卡 09 出生，还没有任何真实使用。法务是否真的需要亲手补录旧合同，是一个我看不见的业务事实——如果实际流程里补录本来就归档案岗，那 §06 那个「或」从一开始就写宽了，B 才是对的。
③ 防 AI 犯错 — 偏 A/B，一致反对现状。今天是最坏的：文档说两个岗位能用，系统只给一个，且没有任何报错 —— 法务打开页面就是看不到按钮，不会有人被告知为什么。下一个作者读 §06 会以为它坏了。A 与 B 都消除这个静默落差，区别只在往哪个方向对齐。C 单独选会让落差持续存在。
④ 创业阶段不扩散 — 明确偏 B。B 零新增；A 增一项能力令牌，而每一个已声明的键都是永久义务。⚠️ 按「零拉动默认 defer 或 remove」，②的零拉动读数直接把这一棱推向 B。
推荐：A，但置信度不高，且我要指出四棱在这张卡上是分裂的。 ①③ 指向 A，②④ 指向 B。按「长远合理性权重恒 ≥50%」推荐 A；但那条权重规则同时说明它「按缩小而非扩大特例读」，而 A 恰恰是扩大 —— 所以这里我不认为权重规则给了 A 一个干净的胜利。若你知道法务实际上不需要自己补录，请直接选 B，那比 A 更符合不扩散。
⛔ 本分析看不见什么：法务岗在真实客户流程里是否需要亲手补录旧合同。这一个事实就能定这张卡，而它只在你那里。
关联
#39 / PR #42（发现处，已合并）· DESIGN.md §06 F16、§04 权限矩阵（受管面）· src/actions/contract-backfill.actions.ts（动作头部已记录此限制）
维护者速读
事情：补录已签合同这个动作（F16「Backfill Executed Contract」），设计方案第 6 章写的是档案岗或法务都能用。实现出来只有档案岗（加管理员）能用，法务看不到这个按钮。
为什么：平台的
requiredPermissions是 AND（要求全部持有），不是 OR。而档案岗和法务没有任何一项共同持有的能力，所以「或」这个语义在今天的平台上表达不出来。实现只好退而求其次，挂在execute_contract上（档案岗 + 管理员持有），法务因此丢了这一个按钮 —— 但法务的其他所有路径都不受影响。发现于卡 09（#39 / PR #42，已合并）。当时没顺手改，因为三个补法里两个要动受管面或平台，不是开发能定的。
你要做的：回一个字母，A、B 或 C。
选项
backfill_contract），同时授予档案岗与法务；动作改挂它requiredPermissions支持 OR 形式」的需求，等它落地业务含义直译
A = 给「补录旧合同」这件事发一把专门的钥匙，法务和档案岗各拿一把；B = 承认补录是档案岗的活，法务要补录就走档案岗；C = 等平台把门锁改成「任一把钥匙都能开」。
四棱分析
os-decision-facets
① 项目长远合理性 — 偏 A。这是一个已声明但兑现不了的能力（§06 说「或」，系统做不到「或」），和这批卡反复在修的形状同一类。A 让实现追上声明；B 削声明去迁就实现，方向相反；C 是正确的长远形态但不在本仓手里。⚠️ 但 A 有一个代价要说破：为一个按钮新增一项能力令牌，是契约增生，和「缩小特例」的方向相反。
② 实际业务拉动 — 弱，且这一棱要求实测。判据是「今天谁撞上」。答案是：没有人，因为这个动作今天刚随卡 09 出生，还没有任何真实使用。法务是否真的需要亲手补录旧合同，是一个我看不见的业务事实——如果实际流程里补录本来就归档案岗，那 §06 那个「或」从一开始就写宽了，B 才是对的。
③ 防 AI 犯错 — 偏 A/B，一致反对现状。今天是最坏的：文档说两个岗位能用，系统只给一个，且没有任何报错 —— 法务打开页面就是看不到按钮，不会有人被告知为什么。下一个作者读 §06 会以为它坏了。A 与 B 都消除这个静默落差，区别只在往哪个方向对齐。C 单独选会让落差持续存在。
④ 创业阶段不扩散 — 明确偏 B。B 零新增；A 增一项能力令牌，而每一个已声明的键都是永久义务。⚠️ 按「零拉动默认 defer 或 remove」，②的零拉动读数直接把这一棱推向 B。
推荐：A，但置信度不高，且我要指出四棱在这张卡上是分裂的。 ①③ 指向 A，②④ 指向 B。按「长远合理性权重恒 ≥50%」推荐 A；但那条权重规则同时说明它「按缩小而非扩大特例读」，而 A 恰恰是扩大 —— 所以这里我不认为权重规则给了 A 一个干净的胜利。若你知道法务实际上不需要自己补录，请直接选 B，那比 A 更符合不扩散。
⛔ 本分析看不见什么：法务岗在真实客户流程里是否需要亲手补录旧合同。这一个事实就能定这张卡，而它只在你那里。
关联
#39 / PR #42（发现处，已合并）·
DESIGN.md§06 F16、§04 权限矩阵（受管面）·src/actions/contract-backfill.actions.ts（动作头部已记录此限制）