import Spec.Prelude

/-!
# Permission —— 角色、能力与授权

ADR-0004:权限走"飞书云文档式"——**协作者授权(grant)与操作设置(settings)
分离**;grant 是 `resource + principal + role`,role 取自封闭的 `read / edit /
manage`,且 **read ⊂ edit ⊂ manage** 累积赋能;强制释放锁是 **admin-only**,在
role 体系之外。本模块把这套结构与"高 role 含低 role 全部能力"的单调性钉死。
-/

namespace Spec.System

/--
协作者角色(`PINNED` 封闭, ADR-0004 逐字 "roles are read, edit, or manage")。

与 element-kind / RunState 不同,这里 ADR **明示**只有三个 role,故 `inductive`
是封闭授权,不是"尚未封闭"。
-/
inductive Role where
  | read
  | edit
  | manage

/--
角色的**赋能层级**(`PINNED` 序, ADR-0004 read⊂edit⊂manage)。

把 ADR-0004 的累积包含关系数值化:read=0 ⊂ edit=1 ⊂ manage=2。它只服务于下面的
`Role.le` 与能力推导,不对外承诺"层级就是个 `Nat`"。
-/
def Role.level : Role → Nat
  | .read => 0
  | .edit => 1
  | .manage => 2

/-- 角色偏序:`r₁ ≤ r₂` 即 `r₁` 赋能不强于 `r₂`(`PINNED`, ADR-0004)。 -/
def Role.le (r₁ r₂ : Role) : Prop := r₁.level ≤ r₂.level

/--
受 role 调控的操作能力(项 `PINNED` 取自 ADR-0004;**枚举完整性 `OPEN`**)。

逐项来源于 ADR-0004 对各 role 的展开:`view`(read);`discussComment` /
`editArtifact` / `triggerAgent` / `answerChoiceCard`(edit);`manageCollaborators`
/ `projectSettings` / `groupBinding` / `normalCancel`(manage)。

⚠ **完整性 OPEN**:这是 ADR 当前点名的能力,不保证穷尽;新增产品操作时可能扩。
注意 **force-release 不在此列**——它是 admin-only override,见 `RequiresAdmin`。
-/
inductive Capability where
  | view
  | discussComment
  | editArtifact
  | triggerAgent
  | answerChoiceCard
  | manageCollaborators
  | projectSettings
  | groupBinding
  | normalCancel

/--
某能力所**要求的最低角色**(`PINNED`, ADR-0004 各 role 的能力展开)。

read 级仅 `view`;edit 级是讨论/评论、编辑产物、触发 Claude、应答 choice card;
manage 级是协作者管理、项目设置、群绑定、常规取消。授权判定 `Role.can` 据此定义,
从而"谁能做什么"只有这一处真相。
-/
def Capability.requiredRole : Capability → Role
  | .view => .read
  | .discussComment | .editArtifact | .triggerAgent | .answerChoiceCard => .edit
  | .manageCollaborators | .projectSettings | .groupBinding | .normalCancel => .manage

/--
角色 `r` **具备**能力 `c`(`PINNED`, ADR-0004)。

定义为"`c` 要求的最低角色 ≤ `r`"。这一处定义同时编码了 read⊂edit⊂manage 的累积性:
manage 自动具备所有 edit / read 能力,无需逐条列举。
-/
def Role.can (r : Role) (c : Capability) : Prop := c.requiredRole |>.le r

/--
**单调性**:角色越高,能力只增不减(`PINNED` 定理, ADR-0004 累积赋能)。

这是 read⊂edit⊂manage 的形式化保证:若 `r₁ ≤ r₂` 且 `r₁` 能做 `c`,则 `r₂` 也能。
证明即偏序传递性——之所以成立得这么干净,正因为 `can` 是按"最低角色阈值"定义的。
-/
theorem Role.can_mono {r₁ r₂ : Role} {c : Capability}
    (h : r₁.le r₂) (hc : r₁.can c) : r₂.can c :=
  Nat.le_trans hc h

/--
**强制释放锁**要求 admin,**在 role 体系之外**(`PINNED`, ADR-0004 admin-only override)。

ADR-0004 明确:force release 卡住的锁是异常操作,不是任何协作者 role 的能力——
即便 `manage` 也不经由 `Role.can` 获得它。故它不是一个 `Capability`,而是这样一个
独立谓词:仅当主体是 admin 时成立。`isAdmin` 由平台另行判定(本层不建 admin 模型)。
-/
def RequiresAdmin (isAdmin : Prop) : Prop := isAdmin

end Spec.System