forked from EduCraft/curriculum-project-hub
sjfhsjfh
f1dce07789
Picture the whole framework, then pin the element-kind language layer. System platform layer — rebuild the semantics likec4 can't draw (ADR-0001..0004): - Prelude: opaque Identifiers carrier (ProjectId/RunId/SessionId/Principal) - System/Run: RunState + Terminal subset (set completeness left OPEN, no invented pending) - System/Lock: lock owner=run (typed), LockTable exclusivity, WellFormed invariant (a lock holder must be a non-terminal run — couples Lock and Run) - System/Permission: read<edit<manage role lattice, capability derivation, can_mono monotonicity theorem; force-release sits outside the lattice (admin-only) - System/Audit: intentionally thin (mostly plumbing, OPEN) Courseware product layer — split the single Lesson file into focused modules and fix doc tautology: Primitives / Element / Lesson / Render / Diagnostic, plus QuestionBank and Course skeletons (core relations OPEN, not invented). Diagnostic upgrades WarnsIgnored into a severity-tagged checker rule. Element schema + rich-content model (ADR-0006, ADR-0007): - docs/adr/0006: kind schema is declarative JSON Schema; field types are built-in scalars plus a `content` extension; a `content` value is typst source taken as module body; rich content must carry a VirtualPath (else click-to-jump and relative import break — verified against typst source); import boundary = within the engineering file + @package - docs/adr/0007: on-disk form is a real directory tree (agent/grep friendly); VirtualPath = real relative path; layout conventions deferred - spec/Courseware/RichContent: prose anchor for rich content (opaque VPath, RichContentRef); ElementData kept abstract — JSON/typst internals are implementation detail, not contract lake build green (18 jobs), no sorry, toolchain v4.31.0. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
100 lines
3.7 KiB
Lean4
100 lines
3.7 KiB
Lean4
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
|