# 任务 / 讨论串 / 频道协作者策略

> 规范路径：`specs/task/collaborator-policy.md`
> 相关规格：
> - [`specs/task/agent-space-convergence.md`](agent-space-convergence.md)
> - [`specs/task/embedded-view.md`](embedded-view.md)
> - [`specs/task/board.md`](board.md)
> - [`specs/message/delivery-ledger-optimization.md`](../message/delivery-ledger-optimization.md)

状态：目标规格 / V1 收口。本文定义 Task / channel / thread 的 owner-scoped private-agent collaborators、Scope Execution 和 private agent context eligibility / delivery boundary。目标是承接旧 owner-private execution container 的能力，但不要求用户理解或打开旧 private-context 产品对象。

2026-05-06 V1 收口：本版本只交付 **People list 向下继承**。collaborator 必须是被 owner 显式加入的具体 human member 或已安装 app 的 service member；channel-level People 可以被 thread / source task 继承，thread-level People 可以被 thread 下创建的 task 继承。例如 thread collaborator 可以在该 thread 下创建的 task discussion 内发言。V1 不交付“分享整个 thread / channel 给 agents”的 whole-scope range sharing，不把普通 thread/channel member 自动视为 collaborator，也不把未来加入 thread/channel 的人自动带入 collaborator list。

2026-05-18 App collaborator 收口：installed app 在 People collaborator UI 中作为同一种 collaborator 候选被添加 / 移除，复用 People collaborator 的 owner、scope、role、expires、removed/left 有效期语义。app collaborator 不创建普通 source scope `scope_memberships`，也不授予 app 读取 channel/thread/task 历史；它只表示该 app service member 在授权有效期内写出的 app-authored 消息可以进入对应 owner 的 private-agent context eligibility / wake/read 语义。

2026-05-06 收敛：Task-first 不等于 Task-only。旧的 `(owner, channel)` / `(owner, thread)` private execution context 在最终态应变成 `(owner, channel)` / `(owner, thread)` Scope Execution，而不是默认变成 task-board 上的 channel task / thread task。explicit task 也语义绑定自己的 `(owner, task)` Scope Execution；owner-only task 由 task row 承担 execution identity，不要求默认创建空 execution row。collaborator list 是这些 Scope Execution 的实际协作边界，不是普通 channel/thread member list，也不是仅用于未来 task 的 defaults-only 配置。V1 collaborator 是具体个人或已安装 app；用户看到的是“这个 owner 的 private agents 被授权和哪些协作者协作”，而不是一套新的用户可见空间概念。

2026-05-07 成本收敛：owner 授权 list 必须被建模成独立的 owner authorization metadata，而不是复用 source thread/channel 的普通 participants，也不是把消息搬进一个新的 transcript space。source scope 继续存消息；owner authorization metadata 只存 owner 授权的 People。owner-only 是缺省 fast-path：没有 collaborator/share/wake/open detail 的 `(owner, scope)` 不创建 execution row、不创建空 collaborator metadata row、不查询 People。前端不得在 thread/task 首屏为了所有可见历史消息默认解析 `privateAgentContextState`；消息级 eligibility 只在 agent/context 操作、菜单展开、批量选择、实时新增消息提示等有明确意图时按小批量懒加载。为避免非授权发送者反馈不明显，UI 可以读取当前 viewer 在该 owner+scope 下的轻量 contribution capability，但这个能力查询不得扫描消息。private-agent wake access 同样不得在 channel/thread 首屏枚举所有 owner；`@prefix` 候选按当前 source scope、prefix 和 hard limit 懒加载，发送路径对实际 mention tokens 做最终授权。owner 的 own private agents 走 fast-path；非 owner 候选只对小批量 candidate owners 批量查 People grant。

2026-05-05 存储收敛：`scope_memberships` 保持原始语义：真实 member 是某个 scope 的 participant / read-state row。V1 People/direct member collaborators 用 `task_scope_participant_metadata` 表达。whole thread/channel range sharing 属于未来未交付设计；本版本不维护 boundary table、execution hint、公开 API 或前端 contract，也不得把它作为新增授权入口、默认操作路径、context eligibility、wake 授权或 owner-private history 可见性来源。

2026-05-05 轻模型假设：owner-only 是默认态，collaborator 是稀疏例外。owner 自己不写 participant row；没有授权 / share / wake / open detail 的 channel/thread/task 不写 execution row、空 cache row 或空 scope row。普通消息写路径完全不知道 collaborator；private-agent context load 才解析已有 owner+scope execution，并按有限 source-chain indexed lookup 组合 People。

2026-05-06 UX 收敛：用户界面不得把 `Boundary` 当作用户概念，也不得把 channel/thread collaborator 管理显式塞进普通 channel member / thread member 列表。飞书云文档权限模型只作为交互参考：权限入口属于“分享 / 权限”语境；协作者列表把对象和权限放在同一行。AgentTeam V1 对应的用户心智是“把某个具体人或 app 加入我的 private agents 可协作人员列表”。默认 UI copy 应使用 `智能体协作者` / `Agent collaborators`、`People` 和 `Can provide context` 等词，不出现 `Boundary`、`grant`、`execution owner`、`scope task`、`resolver`，也不提供 `Share this thread` / `Share this channel`。`Scope Execution` 是开发规格和内部诊断术语，不是默认用户文案，也不是 legacy。

2026-05-20 智能体协作者入口收口：`智能体协作者` 是 owner 主动管理自己 private agents 协作者的聚合入口。它默认只展示当前登录 owner 已显式授权且仍 active 的 human / app collaborators，按人或 app 聚合，并可按 channel / thread / task 反查具体场景。新增授权必须从具体场景入口发起；聚合页用于查看、撤销、调整或跳转，不用于发起宽泛授权。workspace owner / admin 不得查看、管理、枚举其他 owner 的智能体协作者。

## 1. 一句话定义

**Collaborator 是 owner 显式授权给自己 private agents 的具体 human member 或已安装 app service member。这个授权挂在 channel/thread/task Scope Execution 上，并可按 channel <= thread <= task 的 source chain 向下生效。**

用户只需要理解：

- explicit Task 是 owner 和 private agents 工作的 task-shaped 执行容器；
- channel/thread 可以拥有 owner 维护的 People collaborator list，内部由常驻 Scope Execution 承接；
- collaborators 是 owner 显式加入的具体人员或 app，不来自整个 thread/channel 范围；
- collaborator 的消息可以成为该 scope/task agents 的上下文，但普通消息不等于递交 / 唤醒；
- owner 或 collaborator 明确 `@private agent` / explicit wake 时，才触发 private agent delivery；
- 非 collaborator 的普通消息默认不进入该 owner 的 private-agent context，owner 可以通过 Share/Forward 生成具体 owner_quote 消息显式分享；
- 旧 private-context implementation reference 只是分支本地基座，不是用户概念；Scope Execution 是最终态内部模型，不是 legacy 兼容面。

不要把 collaborator 解释成：

- 普通 channel member / thread participant 的同义词；
- 每条消息的 delivery / fanout list；
- private agent 每句话都必须响应的触发器；
- 自动把历史消息复制给 private agents 的 backfill 规则；
- 把 thread/channel 全员永久展开成 task-local member rows 的同步任务；
- 用户可见的旧 private-context product object。
- 普通 shared `scope_memberships` / read cursor row 的同义词。

## 2. 核心心智

V1 必须区分两件事：

```text
context eligibility / visibility
  private agent 在某个 scope/task execution container 中可使用哪些消息作为上下文

delivery / wake
  哪些消息会触发 private agent 被递交、启动或要求回复
```

collaborator 解决的是第一件事：谁可以向这个 scope/task execution container 写入可用上下文。collaborator 不表示每条普通消息都会唤醒 private agent。

这需要同时区分三个层次：

```text
source scope
  普通 channel/thread 消息实际发生的位置
  继续使用普通 channel/thread membership 决定人类可见性

owner authorization metadata
  (owner, source scope) 的私有智能体授权列表
  通过 collaborator metadata 表达 owner 显式授权的 People/app collaborators，不存消息
  可以不存在；不存在表示 owner-only

scope execution container
  owner 的 channel Scope Execution / thread Scope Execution / task Scope Execution
  决定 private agents 可以把哪些 source messages 当成工作上下文
```

source scope 消息默认不复制进 task discussion，也不写入 owner authorization metadata。scope/task 在读取上下文、执行诊断或处理 wake 时，按 owner、source scope、collaborator grant 和 effective global seq 区间组合可用材料。只有显式 Share/Forward owner_quote、task discussion、artifact、announcement 等动作会写 task/message-native context/audit facts。

Scope Execution 承接旧 owner-private execution container：

```text
(owner, channel) private context  ->  owner's channel Scope Execution
(owner, thread) private context   ->  owner's thread Scope Execution
(owner, explicit work)        ->  explicit task + task Scope Execution
```

同一个 channel/thread 中，不同 owner 可以有不同的 Scope Execution：

```text
(Wink, #project) channel Scope Execution
(Alice, #project) channel Scope Execution
(Wink, thread-123) thread Scope Execution
```

这些 execution contexts 有自己的 participant/grant boundary、context eligibility、diagnostics、wake state 和 audit。只有 explicit task 或产品需要的 task-facing projection 才拥有完整 task detail / discussion / artifact / read-state surface。

有效协作者也不应该只隐藏成系统内部 union。UI 应像文档授权列表一样展示：

```text
智能体协作者 / Agent collaborators
  Alice                  Person · Added on this task
  GitHub                 App · Shared from this channel
```

直接添加人员或 app 会产生具体 member collaborator。V1 不提供 boundary / range 授权入口，因此不能出现 `This thread`、`#project` 这类整范围 collaborator 行；普通 channel member / thread participant 不会仅因可见性而成为 collaborator。

channel 级继承不等于全 channel participants。只有 owner 显式添加的 channel-level collaborator grants 才会进入这个 owner 的 private-agent 协作边界。普通 channel member / thread participant 只是基础可见性前提，不是 collaborator grant。

层级关系是授权边界的包含关系：

```text
effective(channel scope) = channel-local collaborator grants

effective(thread scope)  = channel-local collaborator grants
                        ∪ thread-local collaborator grants

effective(explicit task scope)= channel-local collaborator grants
                        ∪ thread-local collaborator grants
                        ∪ task-local collaborator grants
```

因此可以在 task-facing 语境中说：

```text
channel collaborators <= thread collaborators <= task collaborators
```

这个包含关系来自运行时对有限 source chain 的解析：People/direct member collaborators 来自各 owner scope execution 的 collaborator metadata，member 可以是 human 或已安装 app service member。它不来自 channel/thread 普通成员列表，也不通过复制 inherited rows 实现。

## 3. Scope Execution / 范围执行上下文语义

### 3.0 Scope Execution 解析

channel/thread Scope Execution 是 owner-scoped 的常驻执行容器：

```text
resolveChannelScopeExecution(owner, channel)
resolveThreadScopeExecution(owner, thread)
```

它们可以懒创建。创建或解析 Scope Execution 不允许：

- backfill source scope 历史消息；
- copy source messages into execution transcript；
- 为 owner / collaborators / private agents 批量写 delivery rows；
- 把 parent channel/thread collaborators 物化成不可解释的隐藏 rows。

懒创建必须足够克制。以下动作可以成为 Scope Execution / task-facing projection 的创建触发点：

- 添加第一个 owner-private collaborator；
- 第一次 owner / collaborator 明确 `@private agent` 或 explicit wake；
- 第一次 explicit Share/Forward owner_quote；
- owner 明确打开该 channel/thread 的 collaborator management / execution detail 或管理该 scope 的 collaborators。

以下动作不得创建 Scope Execution / task-facing projection：

- 普通 channel/thread 消息写入；
- 普通 channel/thread membership、read-history、read-cursor 更新；
- 普通 message preview / composer preview / unread 推导；
- 仅因为某个 explicit task source chain 指向 channel/thread。

无论何时创建，context eligibility 都从明确的 effective global seq / time 开始。channel/thread Scope Execution 的懒创建只生成最小 projection：execution identity、owner、source scope、必要 audit，以及 People grant metadata。它不得默认占用普通任务看板编号，不得默认创建订阅/read-state/discussion/artifact rows，也不得把 parent channel/thread collaborators 物化成 child rows。只有用户打开 explicit task detail、写 task discussion、添加 context/artifact、watch/subscribe 等具体动作，才创建对应的 task-native rows。

被物化的 Scope Execution 必须有稳定的 execution identity，供 context、diagnostics、delivery target 引用。People collaborator grants 由 `task_scope_participant_metadata.owner_scope_execution_id` 关联到 execution；owner-only channel/thread scope 可以没有 execution row。它可以有 task-facing projection，但不一定默认占用普通任务看板上的人工 task 编号；是否在 UI 中提供 task-facing detail / management entry 是产品投影问题，不影响它作为执行容器的事实身份。

explicit task 的 owner-only execution identity 由 task 自身承担。也就是说，“explicit task 绑定自己的 task Scope Execution”是语义绑定，不要求每个 task 创建一条空 `scope_executions` row。只有 task-local People grants、task-local collaborator 管理、或必须引用内部 scope-execution target 的运行时路径，才创建 / 复用 `(owner, task)` execution row；该 row 不携带单独 collaborator edge column；grant edge 由 `task_scope_participant_metadata.owner_scope_execution_id` 表达。

### 3.1 Channel Scope Execution / 频道范围执行上下文

channel Scope Execution 是 owner 绑定到某个 channel 的常驻 private-agent execution container。

效果：

- owner 的 private agents 在这个 channel scope 中工作；
- channel scope collaborators 是 owner 在这个 channel Scope Execution 上的 local collaborator grants；
- owner 和 collaborators 在该 channel 中的普通消息可以进入这个 channel scope 的 context-eligible stream；
- owner 和 collaborators 的普通消息不会仅因为可见就触发 delivery；
- owner 或 collaborator `@private agent` / explicit wake 时，才触发 private agent delivery；
- non-collaborator 消息默认不进入这个 channel scope，除非 owner 显式 share。

### 3.2 Thread Scope Execution / 讨论串范围执行上下文

thread Scope Execution 是 owner 绑定到某个 thread 的常驻 private-agent execution container。

效果：

- thread scope collaborators 是 channel-local grants 与 thread-local grants 的 effective union；
- owner 和 collaborators 在该 thread 中的普通消息可以进入这个 thread scope 的 context-eligible stream；
- owner 和 collaborators direct mention private agents 时，可以触发 delivery；
- non-collaborator 消息默认不进入这个 thread scope，除非 owner 显式 share；
- thread scope effective collaborators 包含 channel-local grants，但不复制历史消息，也不复制 inherited rows。

### 3.3 Explicit Task / 显式任务

explicit task 是用户显式创建的 task。

效果：

- explicit task 语义上绑定自己的 task Scope Execution；owner-only identity 由 task row 自身提供，不要求创建空 execution row；
- explicit task collaborators 是 source channel/thread grants 与 task-local grants 的 effective union；
- task discussion 中 owner 和 active collaborators 的消息可被 task agents 使用；
- explicit task 不需要复制 source thread/channel collaborators；运行时按来源链路解析 effective collaborators；
- 如果产品需要把某个继承 collaborator 固定到 task-local，必须是 owner 显式 Add on this task。

## 4. 上下文可用性

### 4.1 普通频道 / 讨论串消息

普通 channel/thread 消息进入 owner private-agent context eligibility 的规则：

```text
author is owner
  -> context-eligible for owner's bound channel/thread Scope Execution

author is active direct collaborator of that bound channel/thread Scope Execution
  -> context-eligible for that scope from the collaborator relation effective point

author is not owner and not active collaborator
  -> not context-eligible by default
  -> owner may explicitly Share/Forward it as an owner_quote message
```

这不是普通 transcript visibility policy。普通 channel/thread 的读权限仍由普通 channel/thread membership 决定。这里定义的是 private agents 在 owner 的 scope/task execution container 中可使用哪些消息。

普通 source-scope 消息被判定为 context-eligible 时，也不表示它被写入了 task discussion。V1 应优先通过 source refs、effective global seq range 和 indexed message scan 在读取时组合；只有显式 task discussion message、`owner_quote` source-ref message、artifact 或 announcement 才写对应 transcript/audit rows。

### 4.2 Task Discussion / 任务讨论

Task discussion 中：

- owner 消息可被 task agents 使用；
- active task collaborators 的消息可被 task agents 使用；
- inactive / removed collaborators 的未来消息不再进入 task agents 可用流；
- 历史 discussion / owner_quote source refs 保留 source author、authorized by owner、relation id 和 audit。

#### 4.2.1 Agent Task 授权：canonical Task → active board Channel（#t2632/#t2633）

Agent 对 Task（discussion / reaction / subtask / message / workflow workScope 等）的**授权**一律由服务端从 active Task/board 权威关系解析唯一 Channel，再验证同 workspace 的 active Agent+Machine+Member 当前拥有该 Channel 的 active membership。client 提交的 channel/taskScope 只能作为定位或一致性校验，**不能成为授权事实**。

- 单一共享 resolver + ACL：`access.ResolveActiveTaskBoardChannel` 从 active Task scope 与 `tasks.board_id -> task_boards` 解析 board 权威 Channel，验证 workspace 一致性，并对 null/orphan/legacy 无 board 与 denormalized `tasks.channel_id != task_boards.channel_id` mismatch 一律 fail-closed；`access.AuthorizeActiveAgentTaskBoardChannel` 再验证同 workspace `members(type=agent,status=active)`、active Agent、active Machine、active Channel scope membership。taskboard / app / reaction / message 入口都委托它，不复制多套 SQL。
- SQL 读面（ScopeAPI history/search/read-check、visible-scope authorizer、task discussion delivery/responder）使用同一 board-derived 片段：`tasks.board_id -> task_boards` 且 `t.channel_id = task_board.channel_id`（mismatch 即不可读）。仅 legacy-compat 状态投影（`t.board_id IS NULL AND tb.channel_id = t.channel_id`）允许 fallback，且只用于生命周期/时间线投影，不是授权事实。
- slug 与 ID 两种 taskboard 路径调用同一 helper。
- 直接 Task `scope_memberships` 只承担状态职责（participant / watch / notification / unread-read cursor / participant projection），可在授权后惰性物化；保留的 Task membership 在 Channel 撤销后不授予任何能力。
- fail-closed / non-enumerating：伪造其他 Channel、跨 workspace、孤儿/legacy 无 board、denormalized channel mismatch、删除/归档的 Task 或 Channel、inactive Agent/Machine/Member、kind mismatch / 不可解析 target、撤销与并发 delete/move/migration 都返回统一的 forbidden 结果。
- 授权基础 metadata 一律使用真实的 `task_board_channel`（scope 为实际解析出的 Channel scope，而非 Task scope），不再使用 `task_collaborator_grant` / Task-membership 伪装成授权事实。
- 可执行 guardrail：`guardrails/message/task-channel-authority-inventory.go`（+ 提交的 digest inventory `task-channel-authority-inventory.gen.go`）对 production 非测试 Go 做结构化 Go-AST/常量折叠 inventory：枚举每个引用 `scope_memberships` 的 SQL 表达式（含拼接常量）、规范化标识符使 alias 改名无法绕过，并对每个 digest 与提交的 inventory 精确比对；任何 new/changed/unclassified 一律失败。状态-only allowlist（watch/notification/unread/read-cursor/participant projection）与 canonical resolver 精确收录；self-tests 证明 alternate alias、scope-first、拼接 SQL 绕过都会失败。

##### 4.2.1.1 入口/路由矩阵（Agent Task / message / workflow / watch / reaction）

| 入口 | 授权路径 | forward（Channel member / 无 Task membership） | reverse（无 Channel / 保留 Task membership） |
|---|---|---|---|
| taskboard get/list | `resolveAccessibleAgentBoard`（board-derived）+ `ensureAgentCanAccessTaskChannel` | ✓ | ✗（fail-closed） |
| taskboard create-child | `resolveAccessibleAgentBoard` | ✓ | ✗ |
| taskboard update/claim/status/assignee/member/watch/discussion | `resolveAccessibleAgentBoard` + canonical authorizer | ✓ | ✗ |
| task discussion send（raw task-scope） | `authorizeAgentTaskScopeDiscussionWrite` → board-derived `lockTaskRow` + `ensureAgentCanAccessTaskChannel` | ✓ | ✗ |
| message send/reply/history/search/read-check | `ResolveTaskForAgentTaskScopeTarget` → `AuthorizeActiveAgentTaskBoardChannel`；读面走 board-derived readable predicate | ✓ | ✗ |
| workflow workScope/relatedScopes | `AuthorizeWorkflowRunCallbackScopeTx` → taskboard discussion write authority / visible-scope | ✓ | ✗ |
| attachment/reaction | `authorizeAgentTaskAttachmentScopeForMember` / `loadTaskReactionTargetForMember` → `AuthorizeActiveAgentTaskBoardChannel` | ✓ | ✗ |
| unread/conversation projection | 状态-only（self Task membership），仅授权后物化 | — | — |

全部行共享一个 canonical resolver 或一个携带同一不变量的 board-derived SQL 片段；其他-Channel spoof、cross-workspace、null/orphan/mismatched board、deleted/inactive Task/board/Channel/principal、revoke 与并发 delete/move/migration 均 fail-closed、non-enumerating。

### 4.3 显式分享

显式 share 是 non-collaborator 材料进入 owner-private/task 执行上下文的默认路径。当前默认载体是具体消息化的 `owner_quote`：用户通过 Share/Forward/选区分享确认发送后，在目标 channel / DM / thread 写入一条新的 `scope_messages` 行，并在 content/metadata/source refs 中保留被引用消息的来源。

默认入口包括：

- Share/Forward selected messages as owner_quote；
- share thread/channel slices by materializing owner_quote messages；
- share another task / task artifact through structured quote / artifact / announcement messages。

这类 share 是材料分享，不是 collaborator 授权。它可以把一条消息、一段 thread、一个 channel 片段或另一个 task artifact 以具体 owner_quote 消息带入当前执行上下文，但不会让 source author 或整个 source boundary 未来的新消息自动进入 task。

每条 shared message 必须保留：

```text
source surface
source message / range / artifact
source author
shared by / authorized by
frozen quote / source refs
created at
```

### 4.4 范围分享 / boundary grant（V1 deferred）

V1 不提供 whole thread/channel range sharing：不能把整个 thread、整个 channel、或未来加入该 thread/channel 的成员一次性变成 collaborator。

本版本只允许 owner 把具体 people 加入 collaborator list。未来如果重新引入 range/group sharing，必须重新走规格确认：明确“加入 thread/channel”的定义、未来加入者是否生效、历史消息是否 backfill、被覆盖成员如何发现/退出，以及为什么不会被用户理解成把整个 thread/channel 变 public。

## 5. 递交 / 唤醒

context eligibility 不等于 delivery。V1 递交规则：

```text
owner ordinary message in bound scope
  context-eligible
  no durable delivery by default

collaborator ordinary message in bound scope
  context-eligible
  no durable delivery by default

owner direct mention / explicit wake / task dispatch
  context-eligible
  writes sparse targeted delivery event

collaborator direct mention / explicit wake / task dispatch
  context-eligible
  writes sparse targeted delivery event
  behaves like owner for that task boundary

non-collaborator ordinary message
  not context-eligible
  no delivery

non-collaborator direct mention of owner private agent
  no direct delivery to owner private agent by default
  owner may share / approve / add collaborator
```

这意味着：

- collaborator 在 channel/thread 说一句普通话，不要求 private agent 立即响应；
- collaborator 明确 `@private agent`、点击 wake、或通过 task-bound composer dispatch 时，表现得和 owner 一样，可以触发递交；
- 递交目标是该 owner 的 channel/thread/task Scope Execution，不是 source scope 的普通 broadcast delivery；
- delivery ledger 只记录 direct mention / explicit wake / task dispatch 等 sparse targeted facts；
- 不为每条 context-eligible 消息写 per-recipient delivery row。

公开 / shared agent 的递交规则是另一条产品路径，不应和 owner private agent 的 collaborator boundary 混在一起。

### 5.1 Private-agent `@` 候选与发送授权

private-agent wake authorization 分成两个 intent surface：

```text
autocomplete / candidate discovery
  用户正在输入 @prefix，需要少量可选候选

message send / explicit wake
  用户已经发送或点击 wake，需要最终授权并写入 sparse delivery
```

普通 channel/thread 打开、composer 初始化、普通消息列表加载都不得为了 private-agent wake access 枚举当前 channel 下所有 private-agent owners，也不得预先计算 “viewer 可以 wake 哪些 owner”。这种 broad access list 不是普通 transcript state。若旧 `private-agent-wake-access` 风格 endpoint 在 lazy flow 落地后没有生产调用，应删除 route、API client、port、service method 和测试，避免未来误用。

owner fast-path：

```text
candidate.ownerMemberID == authorMemberID
  -> can show / can wake
  -> no People lookup
  -> no collaborator metadata lookup or row required
```

非 owner private agents 只有在当前 viewer 是该 owner 在当前 source chain 上的 active People collaborator 时，才可以作为候选展示或被 wake：

```text
candidate.ownerMemberID != authorMemberID
  -> batch check People grants for candidate owners
  -> check only current bounded source chain
  -> no whole-channel owner enumeration
```

`@prefix` lazy candidate resolver 的 contract：

```text
input:
  workspaceID
  viewerMemberID
  source scope: channel | thread | task
  prefix / token
  returnLimit K

steps:
  1. verify viewer can read the current source scope once
  2. resolve host channel and bounded source chain once
  3. load private-agent candidates in that host channel matching prefix/token, capped by candidateScanLimit
  4. partition candidates by owner:
       owner == viewerMemberID       -> fast-path allowed
       owner != viewerMemberID       -> candidate owner set
  5. batch-check candidate owner set against People grants on the current source chain
  6. return at most K allowed candidates, with relation = owner | collaborator and source grant detail when collaborator
```

`K` 是最终返回的 authorized candidate 上限，不是授权前 SQL scan 上限。实现不得简单 `LIMIT K` 后再过滤 unauthorized owners，否则未授权 candidates 可能占满前 K，导致后面本来授权的候选偶然搜不出来。授权前必须使用单独的 `candidateScanLimit` / overfetch cap，并让它同样是 hard limit；如果产品明确接受 underfilled autocomplete 结果，也必须在实现和测试中显式记录这个取舍。

`@prefix` resolver 不得：

- 在普通 thread/channel first paint 中调用；
- 扫描 workspace 下所有 private agents；
- 枚举 host channel 下所有 private-agent owners 再逐个判断；
- 为 owner-only 结果创建 execution row 或空 collaborator metadata row；
- 调用会 cleanup expired participants 或产生写入的 helper。

发送路径是最终事实来源。发送消息或 explicit wake 时：

```text
input:
  content / selected wake targets
  source scope
  authorMemberID

steps:
  1. parse direct mention tokens with hard limit T
  2. load exact private-agent candidates for those tokens in the host channel
  3. apply owner fast-path for author-owned private agents
  4. batch-check non-owner candidate owners against current source chain People grants
  5. resolve owner-private / Scope Execution wake only for authorized, actually mentioned agents
  6. write sparse targeted delivery events only for authorized wake targets
```

Autocomplete 是提示，不是授权事实；发送路径必须重新校验。未授权 exact mention 可以作为普通文本存在，但不能 wake owner private agents，也不能写 targeted delivery。

## 6. 协作者层级

channel/thread/task Scope Execution 都可以有 local collaborator grants。effective collaborators 由来源链路运行时合并，不做 seed copy：

```text
channel scope local grants
  member grant: Alice

thread scope effective grants
  channel scope local grants
  + thread scope local grants

explicit task effective grants
  source channel scope local grants
  + source thread scope local grants
  + explicit task local grants
```

规则：

- channel-level collaborator 不是全 channel participants；
- thread-level collaborator 不是全 thread participants；
- task-level collaborator 不是 task discussion 里出现过的所有人；
- 每一层的 collaborator 都必须来自 owner scope execution 上的 People/direct member collaborator；
- 继承是运行时 union，不复制 inherited rows；
- parent execution 上的 collaborator add/remove/expire 只影响其生效点之后的未来消息；
- V1 不做子层级 deny / override；
- 如果需要让某个 inherited collaborator 脱离 parent 生命周期，owner 必须把它显式加到下层 local grants。

这样可以满足“不想每个 task 都重新授权”的目标，同时避免后台同步、copy-on-create、批量展开和隐藏 row churn。

UI 展示必须保留来源：

```text
智能体协作者 / Agent collaborators
  仅自己 / 2 collaborators

  Alice        Person · Added on this task
  GitHub       App · Shared from this thread
```

## 7. UI 语义

### 7.1 智能体协作者入口与信息架构

channel/thread/task collaborator 管理应归入“智能体协作者 / 权限”语境，而不是普通成员列表语境。它可以在 channel/thread/task detail 的更多动作、context 管理、权限详情或 owner 主动打开的管理面中出现，但不得作为 composer 常驻功能干扰主协作流。打开后的管理面不应与普通 channel member / thread participant 列表合并。

```text
智能体协作者
Agent collaborators
Can provide context
```

默认可见层应含蓄但可见：

```text
智能体协作者：仅自己
智能体协作者：2 人
```

thread/channel/task 的局部协作者入口还应提供一个轻量图标或次级按钮，进入 owner 的 `智能体协作者` 总管理页。这个图标用于“查看全部 / 反查所有场景”，可以携带当前 source scope 作为预选过滤或返回上下文，但不能变成 composer 常驻功能，也不能绕过“新增授权必须从具体场景发起”的约束。

点击后展开的权限面板采用文档权限列表心智：每一行是一个被分享对象，右侧是权限 / 动作菜单。V1 对象只能是具体 human member 或已安装 app service member；不要提供 whole thread/channel range 行，也不要把普通 channel/thread member section 当成 collaborator list。

```text
智能体协作者

Add collaborator...

Alice            Person      Can provide context        ...
GitHub           App         Can provide context        ...
```

V1 只有一种实际权限：`Can provide context`。这个下拉仍然有价值，因为它把“这是一个权限对象”表达出来，并为后续 `Can wake agents`、`Can manage sharing` 等更细权限留位置；如果没有多权限实现，下拉内只提供解释和 `Remove`，不要制造假的可选项。

Add menu 只提供添加具体人员或已安装 app，但新增授权必须由具体场景发起：

```text
Add collaborator...
```

新增流程必须先绑定一个明确的 source scope：一个 task、一个 thread，或一个 channel。用户不能先在聚合页挑选一个人 / app 后再泛选授权范围；这会鼓励过宽授权。聚合页可以提供跳转到某个场景的入口，但实际 add flow 应在对应场景中完成。

不要在 V1 默认 UI 中出现 `Share this thread` / `Share this channel` 这类 whole-scope sharing 动作，也不要显示 `This thread`、`#project` 这类整范围 collaborator 行。channel-level People collaborator grant 不是 whole-channel range sharing；它仍然是“把一个具体人 / app 加入 owner 在该 channel scope 下的 private-agent collaborator list”，并且只从添加点之后生效。

不要使用含糊或实现化文案：

```text
Channel members visible to private agents
Thread collaborator grants
Boundaries
Owner scoped execution
```

因为这些会混淆普通 channel membership、用户可见授权对象和实现层 resolver。

### 7.2 输入框 / 消息信号

owner 视角：

- owner 自己的普通消息：可被自己的 private agents 用作上下文；
- collaborator 的普通消息：如果命中当前 owner 的 channel/thread Scope Execution，则可被该 scope agents 用作上下文；
- non-collaborator 的普通消息：显示 owner-facing signal，提示需要 share。

建议 UI：

```text
Shared with Wink's agents for this thread
```

对 non-collaborator 消息：

```text
Not shared with agents yet. Share for agents to use it as context.
```

可以使用轻量灰底 / muted treatment，但必须避免让发送者误解成普通消息不可见。该提示只解释 private-agent context visibility。

在 agent/context 操作面，或消息级状态已经按意图懒加载存在时，消息行 / 操作面应表达 context eligibility 状态，而不是复用 delivery 状态：

```text
context-eligible        授权后可被 Wink agents 用作上下文，但不会自动唤醒
share-needed           当前不在 private-agent context，owner 可显式 Share/Forward 为 owner_quote
```

前端不应自己猜测 collaborator resolver。需要展示消息级状态时，server/API 应返回 viewer-scoped 的 `contextEligibility` / `privateAgentContextState` 一类状态，至少包含 target task/scope、命中的 relation/source、是否可 share、是否可 wake。这个状态只服务 UI 解释与 owner action，不代表 delivery ledger，也不能让普通消息写路径产生 collaborator fanout。

`privateAgentContextState` 不是消息的全局属性，也不是所有 thread 读者都需要承担成本的默认 message field。它是 `(viewer, target owner, target scope, intent)` scoped 的操作状态：

```text
当前 viewer 正在输入 / 刚发出自己的消息
  使用 contribution capability 显示这条普通消息会不会进入该 owner 的 private-agent context
  不扫描历史消息

owner / 有权限操作者看到别人的消息，准备 Share/Forward / wake
  打开菜单或执行动作时，对当前消息或选中消息小批量解析 action state

普通旁观者阅读 thread
  不显示、不查询 private-agent context state
```

消息级状态必须按意图懒加载，而不是作为普通 thread/task 首屏的默认附带数据：

```text
thread/task 普通消息列表加载
  不为所有可见历史消息调用 privateAgentContextState

打开消息菜单 / 管理智能体协作者 / Share/Forward / wake
  对当前 message 或当前选中 message IDs 小批量解析 privateAgentContextState

实时新增消息需要 owner-facing signal
  只解析新增消息的小批量状态，或使用发送者能力给本地消息先显示安全提示
```

为避免非授权人发送后的反馈不明显，composer / send confirmation 应使用轻量 contribution capability，而不是历史消息窗口状态。该能力只回答当前 viewer 在当前 owner+scope 的 effective source chain 下是否是 `owner` / `collaborator` / `none`，以及是否可 contribute context、wake、share；它必须使用和 message-level resolver 相同的 bounded channel <= thread <= task 继承语义，不能只看 scope-local grants。它不得加载 message IDs，也不得扫描 source messages。

显式 shared 消息必须保留归因：

```text
Shared by Alice from #project/thread-123 into Wink's thread scope
Source: Bob · jump back when allowed
```

shared card / source row 不能看起来像 owner 原创消息，也不能暗示 wake/delivery 已发生。它只说明这份材料已经进入 task/scope context。

owner 视角对 `share-needed` 消息可以提供 hover、diagnostics 或选择态 CTA：

```text
Wink's agents cannot use this yet · Share / Forward
```

该提示只对 owner / 有管理权的 viewer 展示，避免让普通发送者误解“消息在 channel/thread 中不可见”。

### 7.3 直接 @ 信号

候选展示必须遵循 §5.1：

- own private agents 可以作为当前 viewer 的候选出现，不需要 People lookup；
- other owners' private agents 默认不在本地候选中预展示；
- 当 viewer 是当前 source chain 上该 owner 的 active People collaborator 时，`@prefix` lazy resolver 可以返回该 owner 的 private agents；
- collaborator 来源应可解释，例如 shared from this channel / this thread / this task；
- autocomplete 结果过期或被篡改不影响安全性，发送路径仍做最终授权。

当 collaborator `@private agent` 时，composer / send confirmation 应清楚表达：

```text
This will wake Wink's agent for this thread scope.
```

如果这个 collaborator 来自继承 People grant，UI 可以补充来源：

```text
Allowed because Bob is shared from this thread.
```

当 non-collaborator `@private agent` 时：

```text
Wink's private agent cannot be woken from this message.
```

具体文案可更短，但语义必须明确。该场景不得提供“添加为智能体协作者”或等价的一键授权 CTA；未授权 wake 失败属于高风险上下文，默认应安全失败 / 普通文本化，而不是引导风险意识不足的用户顺手授权。

输入框需要提前解释动作结果：

- 普通发送：写入当前 channel/thread；如果作者是 owner/collaborator，可能成为 context-eligible，但不会 wake private agent；
- `@private agent` / explicit wake：写 targeted delivery，唤醒对应 owner 的 private agent for this scope/task；
- Add/share：显式 context ingress，保留来源和授权审计，但不会把 source author 自动变成 collaborator。

### 7.4 People 管理 UI

协作者管理 UI V1 只支持：

- `People`：direct member grants。

UI 必须把它和普通 channel/thread member list 区分开：这里的 People 是 owner 授权给 private agents 的协作者，不是 ordinary transcript visibility，也不是频道/话题全员。

```text
Alice · Added on this task
Bob · Shared from this thread
```

copy 必须持续强调：这是 context eligibility / explicit wake 授权，不是 ordinary message delivery / auto-reply。`Boundary` / `Shared ranges` 不应出现在 V1 默认用户界面。

### 7.5 智能体协作者聚合页

`智能体协作者` 是当前 owner 管理自己 private agents collaborator grants 的聚合页。它应从头像菜单中的个人 / workspace 区域进入，也可以从 thread/channel/task 局部协作者入口中的轻量图标进入；在 sidebar 支持更细层级前，不作为主 sidebar 常驻入口，避免把普通协作导航变成权限中心。

页面主轴按已授权的人 / app 组织，而不是按 channel / thread / task 组织。每一行代表一个 active collaborator identity，并汇总它在哪些具体场景中对当前 owner 的 private agents 生效：

```text
Alice        3 个场景 · 可提供上下文 · 1 个即将过期
GitHub       1 个场景 · app-authored messages only
```

默认列表只显示 active grants。expired / removed / left 历史保留在具体人 / app 的详情或显式筛选中；主列表不是审计日志。

点击某个人 / app 后，详情按场景反查：

```text
Alice
  #project                 channel · active · expires tomorrow
  thread: design review    thread · inherited from channel
  task: launch checklist   task · local
```

详情项必须展示：

- 生效场景：channel / thread / task；
- 来源：local grant 或 inherited from channel/thread；
- 能力：`Can provide context`；如果该 collaborator 显式 `@private agent`，发送路径会做最终授权后 wake；
- 生效窗口：added at、expires at、removed / left 状态；
- 操作：从 source scope 移除、跳转到 source scope、查看历史。

聚合页可以撤销、调整过期时间、打开详情和跳转到 source scope，但不能从空白状态直接新增一个宽泛授权。新增必须从具体 channel/thread/task 的 owner 管理入口发起，使授权保持具体、有限、范围可控。

从 thread/channel/task 入口进入聚合页时，页面可以默认定位到当前 source scope 相关的 collaborator identities 或展示“来自当前场景”的筛选 chip，但主列表仍然是 owner-wide 的按人 / app 聚合视图。该 deep link 必须保留返回当前场景的路径，避免用户进入总页后找不回原 thread/channel/task。

聚合页和对应 API 必须以当前登录 owner 为边界。workspace owner / admin 不能在这里切换 owner，不能查看、管理或枚举其他 owner 的智能体协作者；如果未来需要组织级审计，应作为独立合规产品重新设计。

### 7.6 场景入口与 channel 风险确认

新增 collaborator 的入口按范围分级：

- task/thread：推荐路径，范围具体，适合默认展示在任务协作 / thread 更多动作 / context 管理入口；
- channel：允许，但属于高影响范围，必须展示风险说明并二次确认；
- workspace/global：不提供。

channel-level add flow 必须在提交前展示确认步骤，确认内容至少包括：

- 被添加的人 / app；
- 目标 channel；
- 授权只影响当前 owner 的 private agents，不改变普通 channel membership；
- 该人 / app 在该 channel 后续消息中可以为当前 owner 的 private agents 提供上下文；
- 普通消息仍不会自动唤醒 private agent；
- 授权不会 backfill 已有历史消息；
- 过期时间；如果用户选择不设置过期时间，必须显式确认“不过期”。

二次确认必须是独立的确认动作，而不是普通表单里的隐含默认值。channel-level add flow 不能用预勾选的 no-expiry 或单击添加完成授权。

## 8. 存储方向

### 8.1 Owner+Scope Execution

channel/thread/task 都对应一个 owner+scope execution container。它可以落在 `scope_executions`、task execution projection、internal `scopes` row 或等价结构上；SPEC 只约束语义和成本。Task-facing projection 是可选呈现层，Scope Execution 才是 private-agent context boundary。

概念字段：

```sql
scope_executions (
  id
  owner_member_id
  scope_type                 -- channel | thread | explicit_task
  scope_id                   -- channel_scope_id | thread_scope_id | task_id
  created_at
  updated_at
)
```

规则：

- owner-only、无 collaborator/share/wake/open detail 的 channel/thread scope 不创建 execution row；
- explicit task 的 owner-only execution identity 是 task row；不得仅因为 task 存在或被 source chain 引用就创建空 `(owner, task)` execution row；
- `(owner, task)` execution row 只在 task-local People grants、task-local collaborator 管理、或必须引用内部 scope-execution target 的运行时路径中创建 / 复用；
- People/direct member collaborators 存在 `task_scope_participant_metadata`，通过 `owner_scope_execution_id` 关联到 execution；
- V1 不维护 whole-scope range-sharing hint field，也不维护单独 collaborator edge column；collaborator resolver 的唯一 scope-local grant 入口是 execution metadata。

### 8.2 People / 成员协作者：`task_scope_participant_metadata`

`task_scope_participant_metadata` 保存 owner-scoped People collaborator grants。`scope_memberships` 保持普通 scope member/read-state 语义，不承载 task collaborator edge。

```sql
task_scope_participant_metadata (
  id
  owner_scope_execution_id
  member_id                  -- NOT NULL，真实 human/app service member
  role
  added_by_member_id
  added_at
  expires_at
  left_at
  removed_at
  created_at
  updated_at
)
```

语义：

- 普通 shared / transcript scope membership 和 read cursor 继续用 `scope_memberships(scope_id, member_id)`；
- owner-private People/direct collaborator 用 `(owner_scope_execution_id, collaborator_member_id)`；
- collaborator grants 不复用普通 transcript read-state 语义；
- `member_id` 必须非空，并继续表示真实 member；
- owner 是隐式参与者，不写 owner self collaborator row；
- `scope_memberships` 不包含用于把 boundary 伪装成 participant 的泛化字段，也不包含额外关系哈希；
- `active_key` 约束 active grant 唯一性；
- whole thread/channel boundary grant 不在这里表达。

示例：

```text
Add Alice to Wink's channel scope
  scope_execution = (owner=Wink, scope=channel:#project)
  task_scope_participant_metadata row = (execution, Alice)

Add Bob to Wink's explicit task
  task row = task-456 owner-only execution identity
  optional scope_execution = (owner=Wink, scope=task-456) when task-local People grants exist
  task_scope_participant_metadata row = (execution, Bob)
```

### 8.3 Whole-Scope Range Sharing（not V1）

whole thread/channel range sharing 不属于 V1 产品行为，也不保留 shipped schema / service contract。默认 UI、公共操作路径和本版本验收都不能依赖它，也不能提供新增 whole-scope grant 的入口。V1 runtime resolver 不能用它授予 task discussion ingress、private-agent context eligibility、direct mention / explicit wake 权限或 owner-private history 可见性。

约束：

- 不得把 boundary 当前成员展开成 People rows；
- 不得把普通 channel/thread visibility 当成 collaborator 授权；
- 不得 backfill 授权前已有消息；
- 不得参与普通 message write；
- 未来重新启用前必须重新确认 UI、审计、退出/撤销、未来加入者、安全心智和存储契约，并重新引入明确 migration。

### 8.4 有效协作者解析器

effective collaborators 按有限 source chain 读取，不复制 inherited rows：

```text
channel scope:
  People from channel execution metadata

thread scope:
  People from channel execution metadata
  + People from thread execution metadata

explicit task:
  People from source channel execution metadata
  + People from source thread execution metadata
  + People from explicit task execution metadata
```

解析规则：

- 没有对应 owner+scope execution row 时，该 scope 是 owner-only，resolver 不查 participant 表，也不得为了查询结果创建空 execution；
- 对 explicit task，没有 `(owner, task)` execution row 只表示没有 task-local People grants；resolver 仍必须使用 task row 作为 owner-only execution identity，并继续沿 source channel/thread chain 合并 inherited People grants；
- People/direct member collaborator：作者必须等于 active `task_scope_participant_metadata.member_id`，source message 必须属于该 execution scope 覆盖范围，并且作者仍拥有 source scope 基础可见性；
- inherited grant 不复制到 child scope；
- diagnostics 必须显示命中来源：channel/thread/task execution，以及 People relation。

Owner-private message visibility must treat an active People collaborator as the same kind of bounded private authority as an explicit owner grant for the source scope. The readable window starts at `added_at` and ends at `expires_at` / `left_at` / `removed_at`; it must not backfill rows authored before the collaborator was added. For a thread source, the effective collaborator chain is the thread execution plus its parent channel execution; for a channel source, only the channel execution applies. This rule applies uniformly to ScopeAPI read surfaces: history, search, read-check/source/attachment checks, and activity source-message visibility; it must not be implemented as a separate dense delivery ledger, hidden transcript copy, or agent `/receive` backlog expansion.

### 8.5 轻量读取路径与本地提示

V1 读取路径：

- 普通 message write 完全不读取 `scope_memberships`；
- 普通 thread/task 首屏消息列表不默认调用 message-level private-agent context resolver，也不得为所有可见历史消息预取 `privateAgentContextState`；
- 普通 channel/thread 打开和 composer 初始化不默认调用 broad private-agent wake access resolver，也不得为所有 private-agent owners 预取 wake access；
- contribution capability 可以在 composer / send confirmation / wake control 上读取，但它只解析当前 viewer 与当前 owner+scope effective source chain 的关系，不加载 message IDs，不扫描 source messages；
- `@prefix` private-agent candidate resolver 只在用户输入 mention intent 时运行，按 prefix/token + hard limit 小批量加载 candidates，并对 non-owner candidate owners 批量查 People grants；
- direct mention / explicit wake send path 只对实际 mention tokens / selected wake targets 做最终授权，owner fast-path 不查 People，non-owner owners 批量查当前 bounded source chain；
- message-level private-agent context resolver 只有在 context load、explicit wake、direct mention、打开消息菜单、管理智能体协作者、Share/Forward、批量选择、实时新增消息提示这类需要构造 owner execution context 或解释具体消息状态的路径上运行；
- resolver 先解析有限 source chain 上是否已有 owner+scope execution row；没有 row 就 owner-only fast-path，除 owner / owner private-agent author / explicit share 外无 People eligibility；
- 有 execution row 时，批量读取其 `task_scope_participant_metadata` active People grants，并且按当前 source chain 的最多 channel/thread/task bounded set 进行；
- requested message lookup、source readability check、explicit share lookup、owner-private-agent author check 都必须批量化或复用已加载事实，不得按 message 逐条发 DB query；
- 所有 message lookup 都必须按明确 source scope 和 limit 分页，不能扫描 workspace global seq，也不能递归扫描 descendant thread scopes。

V1 不维护 range-sharing hint field。owner-only 默认态不应为了未来功能创建空 row。

### 8.6 必需的有界索引

规格确认门禁通过前必须明确 context load 依赖的索引契约，避免把复杂度从 delivery ledger 搬到无界读取扫描。

`scope_executions` 至少需要支持：

```text
(owner_member_id, scope_type, scope_id) unique/lookup
(owner_scope_execution_id) lookup
```

`scope_memberships` 至少需要支持：

```text
PRIMARY KEY(scope_id, member_id)
(member_id, removed_at) compatibility/member lookup
```

`scope_messages` 至少需要支持：

```text
direct owner/member collaborator context scan:
  (scope_id, author_member_id, workspace_global_seq, seq)
```

读取约束：

- direct member collaborator 不能靠 `(author_member_id, created_at)` 或 workspace global seq 做大范围扫描；
- broad channel grant 覆盖 thread descendants 时，不能在 context load 里枚举所有 descendant thread scopes；只能读取当前被请求的 channel/thread/source scope；
- explicit task 的 source chain 是有限集合：source channel execution、source thread execution、explicit task execution；不能展开成历史 task graph；
- diagnostics 必须报告使用的是哪类 bounded lookup，便于后续 profiling。

### 8.7 显式分享来源

Explicit share 使用具体 `owner_quote` 消息及其 source refs 承接；不得重新引入旧 add-context 夹心写入口。

```text
scope_messages(message_type = owner_quote)
  target scope: channel / dm / thread
  author: sharing owner
  content / metadata: frozen quote body and attribution

scope_message_sources
  source_scope_id
  source_message_id / source_seq / source range
  source_kind
```

规则：

- sharing a message writes an owner_quote message with source refs；
- sharing a thread/channel/task writes bounded source refs or snapshot policy on the materialized message；
- sharing does not add source author as collaborator；
- diagnostics must distinguish `collaborator context eligibility` from `owner_quote source refs`。

### 8.8 审计 / 通知

授权审计和通知状态不写入 hot `scope_memberships` participant/read-state rows，也不写普通 delivery hot path。

可使用冷表：

```sql
task_collaborator_events (
  id
  owner_scope_execution_id
  target_kind                 -- member
  member_id                   -- target_kind=member
  event_type                  -- add | remove | leave | expire | update_expiry
  actor_member_id
  event_at
  payload_json
)
```

通知 job 可单独排队：

```sql
task_collaborator_notification_jobs (
  id
  owner_scope_execution_id
  target_kind
  member_id
  notification_type
  state
  queued_at
  delivered_at
  failed_at
  error_code
  error_message
  created_at
  updated_at
)
```

这些冷表不得参与普通 message write、ordinary receive/unread，也不得成为 delivery hot path。

通知 / 退出规则：

- direct member collaborator：向被加入的 member 发送 add-collaborator notification；该 member 可以主动 leave，leave 只移除这条 direct member collaborator，不影响 parent channel/thread grants；
- whole-scope range sharing 不属于 V1 通知对象；V1 不把当前 / 未来 thread/channel members 展开成 notification jobs，也不在普通消息写入时 fanout 通知；
- 如果未来需要个人 opt-out，必须新增显式 exclusion / deny 规格，并说明它如何影响 effective union、diagnostics、通知和成本模型；不能用隐藏 removed member rows 模拟。

## 9. 成本模型

普通 channel/thread 写入：

```text
ordinary message write:
  O(1 message row + fixed indexes)
```

禁止：

- 普通消息写入时按 collaborators 做 fanout；
- 为 context-eligible 消息写 per-agent delivery；
- 创建 task 时 backfill 历史消息；
- collaborator relation 变化时批量更新历史消息。

context composition：

```text
thread/task ordinary message list:
  private-agent context state extra cost = 0
  no collaborator metadata creation
  no People lookup
  no message-level eligibility resolver

contribution capability:
  O(1) bounded source-chain scope lookup
  no message scan
  no source message IDs

private-agent @prefix candidates:
  first paint cost = 0
  O(1) query groups + O(K candidate private agents + candidate owners + source-chain length)
  K is hard limited by the autocomplete request
  owner candidates use fast-path; no People lookup for own private agents
  no writes, no expired-participant cleanup

on-demand message-level resolver:
  O(1) query groups + O(N requested messages + active collaborator rows)
  N is explicit message IDs from menu/action/selection/realtime delta, not the visible history window
  no per-message DB query

private-agent context load:
  owner-only path:
    O(owner message index scan + limit)

  People / direct member collaborators:
    O(active member participant rows from existing executions + message index scan + limit)
```

delivery / wake：

```text
direct mention / explicit wake:
  O(1) query groups + O(T mention tokens + C exact candidates + candidate owners + source-chain length)
  T and C are hard limited
  owner fast-path skips People lookup
  writes sparse targeted events only for authorized, actually targeted private agents
```

ordinary owner/collaborator message:

```text
context-eligible only
no durable delivery by default
```

大多数 task/scope 是 owner-only。普通消息写入完全不访问 `scope_memberships`；普通历史消息列表也不默认解析 message-level private-agent context state。private-agent context load 在需要时才沿当前 source chain 解析最多 channel/thread/task 的 owner+scope execution。没有 execution row 就 owner-only fast-path，不能为了读取创建空 row；有 execution row 时只查对应 execution metadata 的 People。消息级状态解析允许对请求的 N 条消息做内存分类，但 DB 层必须保持常数查询组，不能出现 bounded N+1。

## 10. 与旧 owner-private prototype 的关系

| 旧 private-context prototype 概念 | 最终态概念 / 用户投影 | 交付方向 |
|---|---|---|
| `(owner, channel)` private context | channel Scope Execution；用户投影为智能体协作者 / Agent collaborators | scope execution + optional task-facing projection |
| `(owner, thread)` private context | thread Scope Execution；用户投影为智能体协作者 / Agent collaborators | scope execution + optional task-facing projection |
| private-context direct participants | People / member collaborators | `task_scope_participant_metadata(owner_scope_execution_id, member_id)` |
| private-context boundary share | Not V1 | no shipped schema, API, default UI, or public flow |
| private-context share-in | explicit Share/Forward owner_quote | owner_quote source refs / message audit |
| private-context delivery | Direct mention / explicit wake | sparse targeted events |
| private-context panel | Task detail | 不暴露旧 private-context product object |

如果分支本地运行时基座仍使用旧私有 context 存储命名，它也不能成为公开协作者模型。公开产品语义是智能体协作者、explicit task、task collaborators、owner_quote source refs 和 sparse delivery；内部事实来源是 Scope Execution。

## 11. 实施阶段

1. **规格确认门禁**：确认 context eligibility 与 delivery/wake 分离；确认 channel/thread Scope Execution 承接旧 owner-private execution container，且不是 legacy。
2. **Scope Execution projection**：为 owner + channel/thread 解析或懒创建 channel/thread Scope Execution；仅在需要时提供 task-facing projection。
3. **Grant storage convergence**：direct member collaborator grants 使用 `task_scope_participant_metadata(owner_scope_execution_id, member_id, ...)`；普通成员 participant/read-state 继续由 `scope_memberships(scope_id, member_id)` 承担；whole range sharing 不是 V1 行为，不维护 boundary table 或 `owner_private_collaborators` 平行事实表。
4. **Hierarchy resolver**：按 channel <= thread <= task 的来源链路运行时合并 grants；不 seed copy、不 inherited row materialization。
5. **Bounded context lookup**：private-agent context load / explicit wake / direct mention / message action 才按有限 source chain 做 indexed lookup；只解析显式 People collaborator；普通 thread/task 首屏不得默认解析所有可见历史消息的 `privateAgentContextState`，也不得预取所有 private-agent owners 的 wake access。
6. **Context composition**：owner / People member collaborator 普通消息按 source scope + author + effective point 组合进入 owner private-agent context；non-collaborator 消息只通过 explicit Share/Forward owner_quote。
7. **Sparse delivery**：owner/collaborator direct mention / explicit wake 写 targeted event；普通 context-eligible 消息不写 delivery。
8. **UI 收口**：默认用户入口使用 `智能体协作者` / `Agent collaborators`，不要把 collaborator 管理塞进普通 member list，也不要作为 composer 常驻功能打断主协作流；独立聚合页从头像菜单的个人 / workspace 区域进入，thread/channel/task 局部协作者入口提供轻量图标进入该总管理页；聚合页按已授权的人 / app 组织，默认只显示 active grants，并可反查 channel/thread/task 场景；新增授权必须从具体 task/thread/channel 场景入口发起，不从聚合页发起宽泛授权；channel-level 添加必须有风险提示和独立二次确认；未授权 `@private agent` 失败不提供一键添加 CTA；面板只允许添加 People / app；不提供 `Share this thread` / `Share this channel`；composer 区分 context-visible 与 wake；non-collaborator composer / send confirmation 使用 contribution capability 给出明确提示；`privateAgentContextState` 是 viewer+intent scoped 操作状态，不是普通消息的全局字段；历史消息三态按 action/realtime delta 懒加载；private-agent mention candidates 只在 `@prefix` intent 下懒加载，own private agents fast-path，collaborator-visible private agents 来自当前 source chain grants。
9. **验证**：覆盖 People/member collaborator ordinary message context eligibility、channel/thread/task effective union、thread collaborator 可在 thread 下创建的 task 内发言、collaborator direct mention delivery、non-collaborator no delivery/no context without owner_quote share、owner_quote source-ref audit、owner-only bounded lookup、contribution capability 走 effective source chain 且不扫描消息、thread 首屏不调用 message-level private-agent context state、不调用 broad private-agent wake access、`@prefix` candidate resolver hard limit + owner fast-path + batch grant check、message-level resolver 无 per-message DB query、collaborator metadata 不进入普通 read-state 热路径、no per-message fanout、`git diff --check`。

## 12. 验收标准

1. 用户不需要理解旧 private-context product object。
2. channel/thread scope 有最终态内部 execution container：channel/thread Scope Execution；explicit task 语义绑定 task Scope Execution，owner-only identity 由 task row 承担。
3. channel/thread/task collaborators 都是 owner-private collaborator grants，不是普通 channel/thread participants。
4. People/direct member collaborators 由 `task_scope_participant_metadata` 表达；whole range sharing 不属于 V1 行为，不维护 boundary table 或 `owner_private_collaborators` 平行事实来源。
5. channel collaborator <= thread collaborator <= task collaborator 由运行时 effective union 得到，不通过 inherited row copy 得到。
6. whole-scope boundary/range sharing 不作为 V1 授权对象；默认 UI 不出现 `Share this thread` / `Share this channel`。
7. owner、active member-grant collaborators 的普通 source-scope 消息 context-eligible，但不默认 delivery。
8. thread collaborator 可以在该 thread 下创建的 task discussion 内发言，其授权来源记录为 inherited People relation。
9. owner 和 active collaborators direct mention / explicit wake private agents 时，写 sparse targeted delivery event。
10. non-collaborator 普通消息默认不进入 owner private-agent context，也不能直接 wake owner private agent。
11. non-collaborator 消息可通过 explicit Share/Forward owner_quote 进入可读执行上下文。
12. context eligibility 不产生 per-message / per-recipient delivery rows。
13. collaborator add/remove/expire 不 backfill、不批量改历史消息。
14. 普通 message write 不查询 `scope_memberships`；owner-only private-agent context load 只解析已有 execution source chain，未创建 execution 时零行/零查，且不得为读取创建空 execution / empty collaborator metadata。explicit task owner-only path 使用 task row 作为 execution identity；不因 task 存在默认创建空 `(owner, task)` execution row。
15. UI 明确区分“agents can use this as context”和“this will wake agent”。
16. UI 授权列表显示 People，让运行时 effective collaborator 解析可被用户理解；默认用户界面不出现 `Boundary`、`grant`、`execution owner`、`scope task`、`resolver` 这类实现术语。`Scope Execution` / owner authorization metadata 只用于开发规格 / diagnostics。
17. 消息行 / composer 不复用 delivery snapshot 表达 context eligibility；必须区分 context-eligible 与 not-in-context/share-needed。`privateAgentContextState` 不是普通消息全局字段；历史消息列表不默认批量解析所有可见消息的消息级状态；打开 agent/context 相关动作时按小批量懒加载。
18. Owner_quote source refs 保留 source attribution、authorized by owner、snapshot 和 jump-back。
19. composer / send confirmation 必须能让非授权 viewer 明确知道普通消息不会进入该 owner 的 private-agent context；该提示来自 contribution capability，不来自历史消息窗口扫描。contribution capability 必须按 channel <= thread <= task effective source chain 解析授权。
20. channel/thread 首屏、composer 初始化和普通旁观者阅读路径不调用 broad private-agent wake access；`@prefix` 候选只在输入 intent 下按 hard limit 懒加载；own private agents 使用 owner fast-path；other owners' private agents 只在 viewer 是当前 source chain 的 active People collaborator 时展示；发送路径对实际 mention tokens 做最终授权。
21. private-agent wake/access read-only candidate path 不执行 expired collaborator cleanup 或其他写入；写入只发生在授权且实际 targeted 的 direct mention / explicit wake delivery 上。
22. `智能体协作者` 聚合页只展示当前登录 owner 自己已授权的 human / app collaborators；workspace owner / admin 不能查看、管理或枚举其他 owner 的智能体协作者。
23. 聚合页主轴按人 / app 组织，默认只显示 active grants；expired / removed / left 历史只在详情或显式筛选中展示；详情必须能按 channel / thread / task 反查场景、来源、能力、生效窗口和可执行操作。
24. thread/channel/task 的局部协作者入口必须有进入 `智能体协作者` 总管理页的轻量图标或次级按钮；从局部入口进入时可以预选当前 source scope，并必须提供返回当前场景的路径。
25. 新增授权必须从具体 task/thread/channel 场景入口发起。channel-level 添加允许存在，但必须显示风险说明并要求独立二次确认；workspace/global 授权不属于 V1。
26. 未授权用户尝试 `@private agent` 时，发送路径安全失败或普通文本化，并给出克制解释；该失败状态不得提供“添加为智能体协作者”或等价的一键授权 CTA。
27. V1 不交付用户可见旧 private-context flow，也不把旧 private-context object 作为 public API dependency。
28. Scope Execution / owner-scoped private-agent execution context 不被标记为 legacy；legacy 只指旧 exposed target、browser API、panel/flow 和 agent-facing vocabulary。