feat(spec): build out System layer and element schema model

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>

spec/Spec/System/Permission.lean

@@ -0,0 +1,99 @@
+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