import Spec.Prelude

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

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

namespace Spec.System

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

/-- 角色赋能层级(`PINNED` 序, ADR-0004 read⊂edit⊂manage 数值化)。仅服务于
`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 当前点名的能力,不保证穷尽,新增产品操作时可能扩)。注意 force-release
**不在此列**——它是 admin-only override,见 `RequiresAdmin`。 -/
inductive Capability where
  | view
  | discussComment
  | editArtifact
  | triggerAgent
  | answerChoiceCard
  | manageCollaborators
  | projectSettings
  | groupBinding
  | normalCancel

/-- 某能力所**要求的最低角色**(`PINNED`, ADR-0004 各 role 能力展开)。授权判定
`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 的累积性。 -/
def Role.can (r : Role) (c : Capability) : Prop := c.requiredRole |>.le r

/-- **单调性**:`r₁ ≤ r₂` 且 `r₁` 能做 `c` ⇒ `r₂` 也能(`PINNED` 定理, ADR-0004 累积
赋能的形式化保证)。证明即偏序传递性,得益于 `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)。即便 `manage` 也不经 `Role.can` 获得它,故它不是 `Capability` 而是独立
谓词;`isAdmin` 由平台另行判定(本层不建 admin 模型)。 -/
def RequiresAdmin (isAdmin : Prop) : Prop := isAdmin

end Spec.System
