feat: 支持多人共享项目、成员邀请与角色权限

## 来源

- 来源频道：Discord #新人报到
- 原帖链接：https://discord.com/channels/1524291334654132335/1524310899756761169/1536548922900742154
- 提问人显示名称：素人极客
- 脱敏问题摘要：用户希望同一个 Cindy 项目可以由不同成员共同使用，并能为不同成员配置不同权限。

## 用户实际需求

用户最初询问多台 Cindy 设备之间共享能力，进一步确认核心场景不是同一账号的多设备遥控，而是：

- 多个真实用户共同访问同一个项目；
- 不同用户拥有不同操作权限；
- 项目内的文件、资源、任务或会话需要有明确的共享边界。

## 已确认的当前产品边界

截至 2026-08-11，Cindy 的现有能力不能完整满足该场景：

- 项目主要是本地工作目录与会话的组织边界；
- Device Link 面向同一账号的设备互控，不是多人协作或权限系统；
- 会话分享属于导入/导出式快照，不是多人持续协作；
- 当前没有项目成员、邀请、角色或 ACL 数据模型；
- 云盘只能同步文件，无法控制谁能运行 Agent、读取会话、删除内容或管理成员。

因此不应通过共享账号、复用 Device Link 或仅依赖云盘来承载多人权限。

## 产品判断

建议将“共享项目”设计为独立、显式的协作能力，并与本地项目及同账号多设备遥控清楚区分。

建议优先级：P2（新能力，涉及账号、服务端权限和数据边界，需先完成产品与架构设计）。

## 建议的 MVP 范围

### 1. 共享项目与成员

- 项目所有者可以发起邀请、查看成员、撤销成员访问；
- 受邀者必须以自己的 Cindy 账号加入；
- UI 明确区分本地项目与共享项目，并展示当前角色。

### 2. 基础角色

首版建议支持：

- Owner：管理项目、成员与权限；
- Editor：查看并修改允许共享的内容，可按策略运行 Agent；
- Viewer：只读访问允许共享的内容，不可修改、删除或运行有副作用的任务。

### 3. 权限边界

至少需要单独定义并在服务端校验以下能力：

- 查看项目文件与资源；
- 上传、编辑文件与资源；
- 查看任务、会话与上下文；
- 创建或继续任务、运行 Agent；
- 删除内容；
- 发布或导出结果；
- 管理成员与角色。

### 4. 安全与审计

- 未受邀账号不能访问共享项目；
- 撤销成员后，其后续访问立即失效；
- Provider Key、OAuth 凭证和本机私密配置不得随项目共享；
- 对成员变更、权限变更和关键写操作保留最小审计记录。

## 非目标

- 不把共享 Cindy 账号当作协作方案；
- 不把 Device Link 扩展成多人权限系统；
- 不以云盘文件权限替代 Cindy 内部权限；
- 首版不要求多人实时共同编辑同一文件；
- 首版不要求共享所有本地会话、凭证、插件和个人记忆。

## 仍需产品确认

1. 首版共享范围是“文件与资源”，还是也包括任务、会话、上下文和 Agent 接续？
2. AI 执行额度与成本由项目 Owner、任务发起人还是组织统一承担？
3. 是否需要自定义角色，还是 Owner / Editor / Viewer 足够？
4. 删除、发布、运行脚本等高风险动作是否需要单独授权或二次确认？
5. 共享内容的服务端存储、端到端加密与数据区域如何约束？

## 与现有 Issue / PR 的关系

- #1266：Profile 级账号隔离，并明确提出未来 Shared Workspace / Shared Task + ACL；这是本需求的架构前置与相邻边界，但没有实现多人共享项目。
- #1623：解决 Orca 协同模式跨多个本地目录工作，参与者仍是 Agent，不是不同真人账号。
- 本轮已检索 open/closed Issue 以及 open/closed/merged PR，未发现覆盖“项目成员邀请 + 真人角色权限 + 服务端权限校验”的现有实现。

## 验收标准

- 两个不同 Cindy 账号可以通过邀请加入同一个共享项目；
- Owner、Editor、Viewer 的可见内容与可执行动作符合权限矩阵；
- 权限由服务端校验，不能只依赖客户端隐藏入口；
- 非成员无法读取共享项目内容；
- 成员被移除后无法继续读取或写入；
- 共享项目不会同步或泄露个人 Provider Key、OAuth 凭证、个人记忆和本机私密配置；
- 本地项目、同账号 Device Link 与多人共享项目在 UI 和数据模型上可明确区分。

No implementation files or tests are named. Start by reading #1266 and resolving the open product questions, then map the project, member roles, permission checks, invitations, and protected data boundaries across client and server. Done means two accounts can share a project with enforced Owner, Editor, and Viewer behavior, revocation, isolation of secrets, and clear UI distinctions.

Written by the indexing model from the issue text.