Endorphin-Document/guide/02-user-identity.md

2. 用户身份与 workspace 权限

用户身份确定谁在操作，资源归属确定操作的目标，权限确定允许进行哪些操作。平台用同一套身份与权限模型处理代码、基础内容和 agent；代码可视域另行决定声明在程序中的引用范围。

workspace 是资源的整体归属、协作和授权边界。namespace key 使用 workspace handle 定位这一边界，用户身份用于登录、判断操作权限和记录作者。w 表示编辑资源，x 表示使用已定义的程序能力，程序产生业务写入不要求调用者因此成为 Editor。

2.1 Workspace handle 与显示名

Workspace handle 是在平台内唯一定位 workspace 的名称，参与 namespace key。workspace 显示名用于界面展示，可以重复，不承担唯一定位职责。

属性	Workspace handle	Workspace 显示名
用途	唯一定位 workspace 及其 namespace	面向用户展示名称
唯一性	在本平台内唯一	可以重复
参与 namespace key	是	否
示例	atelier	工作室

两个 workspace 可以都叫“工作室”，但其 handle 必须不同。例如 atelier 和 market 是两个 workspace；即使它们的显示名相同，其资源也分别定位。

用户账号与 workspace 是不同对象。一个用户可以参与多个 workspace，一个 workspace 可以有多个用户；资源地址不使用当前用户、管理员或作者的名字作为归属前缀。用户的登录标识及展示名称不决定资源 key，其具体形式见规范状态。

2.2 key 中的 workspace 部分

namespace key 由 workspace handle 与非空 namespace 路径组成：

workspace handle:namespace路径
atelier:shop.ui

冒号前的 atelier 是 workspace handle，不带 @ 前缀；冒号后的 shop.ui 定位该 workspace 内的 namespace。

key	归属 workspace	namespace 路径
atelier:shop	atelier	shop
market:shop	market	shop
atelier:shop.ui	atelier	shop.ui

atelier:shop 与 market:shop 是不同的 namespace，即使它们具有相同的路径或相同的代码内容。

只有 workspace handle 不能构成 namespace key。独立登记的资源还需要至少一级 namespace，完整格式见namespace。workspace 本身的管理入口不由 namespace key 文法定义。

2.3 归属上下文

资源与 workspace 的归属通过代码之外的 key 与索引成员关系关联。读取、编辑和处理代码时，系统使用该归属上下文。

函数名、变量名、注释、字符串和存储对象名均不定义归属 workspace。两段内容相同的代码分别关联不同 workspace 时，其归属上下文仍然不同。

正文中的 use atelier:shop.pricing 表示引用目标，不表示当前代码属于 atelier。例如，market:shop.checkout 可以引用 atelier 的逻辑，其自身归属仍是 market。

2.4 归属 workspace、操作用户与作者

归属主体与用户身份承担不同职责：

身份	含义	关联对象
归属 workspace	资源位于哪个整体归属与授权范围	namespace key 与资源成员关系
操作用户	谁发起读取、修改或执行	本次操作的身份上下文
作者或修改者	谁编写或修改了代码	编辑或历史记录

例如 alice 与 bob 同属 atelier，bob 修改 atelier:shop 的代码时，操作用户和修改者都是 bob，资源仍归属 atelier。退出成员关系或更换管理员不会把资源自动转移到某个用户的个人 workspace。

Agent 或服务代用户操作时同样需要区分操作身份与目标归属。协作、委托和历史记录的具体规则参见规范状态。

2.5 Workspace 与平台用户系统

workspace 是一组资源共同归属、协作和授权的整体，包含 namespace、函数、class、agent 及独立保存的基础内容。用户拥有自己的账号，可以创建 workspace，也可以加入其他 workspace；成员关系不改变用户身份。

注册时创建用户账号，同时创建一个默认个人 workspace，并将注册用户设为该 workspace 的管理员。个人 workspace 和多人 workspace 使用同一模型，差别在于成员数量及其角色；个人 workspace 也可以邀请其他用户加入。

平台可以限制每个用户创建 workspace 的数量。加入已有 workspace 与创建新 workspace 是不同操作，数量上限、计数归属和删除后的额度恢复规则待定。

概念	职责	是否随协作者变化而变化
用户身份	认证操作用户、记录作者与修改者	每位用户独立存在
workspace	承担整体资源归属与权限边界	成员变动不改变资源归属
workspace handle	唯一定位 workspace	改名与历史引用规则需单独定义
namespace	在归属范围内组织和检索资源	不因加入一名成员自动增加一层路径

同一 workspace 中可以包含多组 namespace，各组共享 workspace 的授权边界。成员与资源的关系示意如下：

workspace：atelier
成员：alice、bob

atelier:shop.pricing
atelier:shop.data
atelier:shop.agents

alice 和 bob 编辑同一 workspace 的资源，作者记录各自的用户身份，资源仍归属 atelier。管理员变化或成员退出不要求重写 namespace 引用。默认 workspace 的 handle 如何生成、已有用户名 key 如何迁移，见规范状态。

2.6 r、w、x 的操作分工

三个权限字母表达资源操作的类别；具体角色及其授予范围在 2.7 的 workspace 模型中定义。

权限	允许的操作	不由该权限单独授予的能力
r：读取	浏览获准读取的代码、内容和资源视图	编辑资源、执行程序
w：编辑	创建、修改、删除资源内容或代码定义	修改成员角色、扩大授权
x：执行	调用已定义并允许外部使用的程序入口，取得契约允许的结果	任意改写实现源码或直接管理全部业务数据

w 与 x 的区别是编辑资源和使用程序。修改“提交订单”函数的定义需要 w；使用已经定义好的提交订单能力需要 x。该调用按业务契约保存订单，不要求调用用户获得函数源码的编辑权限。

同样，agent 在既定任务内执行获准业务操作与提交新的代码定义分别处理：使用 agent 的入口需要相应执行授权，向 namespace 保存或修改代码需要目标范围的 w。

程序的业务效果需要受定义好的操作范围、输入、业务条件及调用授权约束。x 不等于调用者获得管理员身份，也不表示能越过入口直接编辑任意资源。具体执行身份和运行能力如何关联仍待定义，不能用“有 x”推导出平台范围的无限授权。

读源码与使用软件可以分别授权。只有 x 的用户可以使用获准入口及调用所需的接口信息，而不因此获得完整实现源码的 r；接口信息的可见范围另行定义。读取函数不会自动运行它，执行后也只取得契约允许交付的结果。

高风险操作仍遵守人工在环等既定执行条件。执行授权与人类确认承担不同职责。

2.7 Workspace 角色与授权

平台按 workspace 记录用户的角色，用角色提供常用权限组合。角色只在对应 workspace 生效，用户在一个 workspace 是管理员，不表示其在其他 workspace 也拥有管理能力。

角色或访问状态	权限基线	管理能力
管理员	rwx	管理成员、角色及 workspace 设置
Editor	rwx	编辑和使用资源，不管理授权
Reader	r--	浏览资源，不修改资源
无访问权限	---	无

管理员与 Editor 的资源权限相同，但管理成员和授权属于管理员角色的管理能力，不增加第四个资源权限位。Editor 不能通过修改普通资源或编写函数为自己授予管理员角色。

Reader 是否附带 x，以及如何向不读源码的用户授予 --x，保留为 workspace 层面的共享与运行授权选择，不为每个函数增加一份独立权限表。未获得 r 与完全无访问权限是不同状态；执行用户可以具有 x 而不具有 r。

角色作用于整个 workspace 的资源，不为每个 namespace、class、字段或函数分别维护访问名单。需要不同协作和授权边界的资源放入不同 workspace，workspace 内通过 namespace 与代码可视域组织结构。

公开或未加入 workspace 的用户也不能仅凭 key 获得访问权。默认公开性、匿名访问以及运行授权的授予方式仍待定义。

2.8 权限边界与 namespace

workspace 是整体授权边界，namespace 是内部组织与检索范围。一个用户获得 workspace 的读取权限，可以在该范围内读取资源；读取某个 namespace 时包含哪些成员，仍由视图成员规则决定。

用户在 workspace 中的角色与授权
    → 允许的 r、w、x 操作
    → 定位目标 namespace 与资源
    → 按该操作和资源契约使用

第一级和后续 namespace 层级具有相同语义，不在每层重新配置权限。权限适用整个 workspace 不等于每次读取父 namespace 都自动合并全部下级内容；授权范围与视图成员范围是两个维度。

namespace key 是定位信息，不是访问凭据。知道 workspace handle 或 key，不等于获得读取、修改或调用其中声明的权限。

2.9 平台权限与代码可视域

平台权限回答“这个操作用户能对目标资源做什么”，代码可视域回答“这个声明能否在当前代码位置被引用”。程序引用或调用需要分别满足对应的可视域与操作权限；查看实现源码则依据读取授权判断。

情况	需要判断的规则
查看一个内部成员的源码	是否具有对应资源的读取权限
外部函数直接引用该内部成员	是否满足声明可见性和名称查找规则
导入并调用一个外部入口	是否可解析该入口，并具有对应执行授权
修改入口或内部成员实现	是否具有目标范围的编辑权限

允许阅读源码不自动允许外部代码引用全部内部成员；声明允许外部引用也不自动向所有平台用户授予权限。use 指定依赖来源，不产生授权。

可视域可以在 namespace、class 或 agent 等程序结构中定义，不要求为每个内部声明建立用户权限表。具体可见性关键字、默认可视域和跨 namespace 名称查找见程序结构与导入。

2.10 操作身份、作者与 Agent

归属主体是 workspace，操作用户和作者是用户身份。作者记录表达谁编写或修改资源，不决定本次操作的权限。

agent 声明位于哪个 workspace，不直接决定本次运行以谁的权限执行。agent 引用一段代码、由管理员编写，或作为某个 workspace 的成员资源存在，都不自动获得管理员的管理能力。

编辑操作检查目标范围的 w；入口调用检查对应的 x 及业务契约。跨 workspace 调用分别判断目标范围的执行授权。角色或授权信息不要求写进每个函数的参数，也不因 use 改变。

程序如何取得操作身份、业务执行能力的绑定和委托、agent 生成代码的提交接口，以及异步任务恢复时的授权检查，仍待定义。

2.11 名称比较与生命周期

创建、检索与改名必须使用一致的 workspace handle 相等判定。两个被判定为相同的 handle 不能同时指向不同 workspace。

workspace 显示名不参与 key，修改显示名不改变资源归属。handle 的变更涉及既有 key 与引用的定位；旧名称复用还涉及历史引用是否继续指向原 workspace。

workspace handle 的字符集合、大小写、Unicode 处理、改名、名称复用和归属转移的具体规则集中列于规范状态。本书示例使用简单的小写 handle 说明结构，不据此限定最终字符集。

管理员交接、成员移除、workspace 停用，以及账号注销后的资源保留仍需明确。成员变化与资源归属分开处理；新请求按当前授权判断，已经运行的调用、实例或任务如何受到授权变化影响另行定义。

2.12 外部模型参考

Linux 文件权限使用所有者、组及其他用户的读、写、执行位，提供了操作类别的参考；本章的 workspace 角色及 x 的程序入口语义由 Endorphin 自行定义。Linux inode 权限说明

Notion 将 workspace 成员关系与页面共享关联起来，提供了协作身份的参考。Endorphin 使用 workspace 整体授权，内部 namespace 负责组织资源。Notion 成员与访客说明

上一章：语言概览 · 下一章：namespace · 目录