# 服务号规范

> Canonical path: specs/service-account/service-account.md
> Status: target-spec
> Scope: workspace 服务号、平台服务号、创建申请与审批、服务身份、Human 管理员、收件人 membership、跨 workspace 广播、普通消息、Inbox、已读未读、权限、存储与验收。
>
> 边界：服务号（Service Accounts）是与「App Integrations / 应用集成」并列的独立产品族（术语以 Service Actor Platform 为准），不归入应用集成。
>
> 相关规范：
>
> - [统一身份规范](../identity/identity.md)
> - [Service Actor、Service Event 与 Automation](../architecture/service-actor-event-automation.md)
> - [Service Actor Platform](../service/service-actor-platform.md)
> - [App 主动通知规范](../app/app-notification.md)
> - [Collaboration Source、Projection 与 Delivery](../collaboration/source-projection-delivery.md)
> - [scope 消息模型](../message/scope-model.md)
> - [Scope Target / Access Contract](../message/scope-target-access-contract.md)
> - [Message Search](../message/search.md)
> - [Message Pin](../message/pin.md)
> - [Message Reaction](../message/reaction.md)
> - [Message Read-path Performance Boundaries](../message/read-path-performance-boundaries.md)
> - [消息未读 Runtime 内存模型](../message/unread-runtime-memory.md)
> - [Delivery Ledger Optimization](../message/delivery-ledger-optimization.md)
> - [Storage](../storage/storage.md)

## 1. 产品契约

产品名称为“服务号”。代码、API 与存储命名空间统一使用
`service_account`。

服务号是由 Human 管理、以自身身份发布消息的 Service Actor。Workspace
服务号由所在 workspace 的 Human 运营；平台服务号由平台运营者统一运营，并在
每个目标 workspace 中物化本地实例。服务号向专属只读消息流写入卡片消息，收件人通过
普通 Inbox、通知、已读未读与搜索能力处理这些消息。

一个 deployment 可以动态拥有零个或多个平台服务号。每个账号拥有独立 principal、
单一名称、资料、workspace instances 与广播序列。服务号不存在 suspend/archive
状态：账号存在即可使用；Delete 是带版本栅栏的永久删除，清除账号专属身份、消息流、
历史消息与编排状态，且不可撤销。

每个服务号根身份拥有：

- 稳定且唯一的名称、头像和简介；
- 稳定 principal 与资料版本；
- workspace-owned 或 platform-owned 管理归属；
- 一个或多个 workspace 本地实例。

每个本地实例拥有：

- 具名 Service Actor installation 与可见作者 member；
- 一个 `type=service_account` 的消息 scope；
- 一个收件人 membership 集合；
- 普通 scope message、Inbox、通知偏好和 read cursor；
- workspace 服务号的 Human 管理员，或平台服务号的平台发布
  authority。

### 1.1 核心对象

| 对象 | 语义 | 权威事实 |
| --- | --- | --- |
| Service Account Principal | 服务号稳定 principal、资料和管理归属 | `service_accounts` 或 `platform_service_accounts` |
| Create Request | Workspace 服务号创建意图、授权路径与物化结果 | `service_account_create_requests` |
| Workspace Instance | 服务号在一个 workspace 内的收件策略、Service Actor refs 与消息 scope | `service_accounts` |
| Platform Instance Binding | 平台服务号与 workspace 实例的生效区间和发布 cursor | `platform_service_account_workspace_instances` |
| Service Actor Identity | 共享产品注册、具名 installation、作者 member、capability、grant 与 target binding | 服务号 principal + workspace instance + Service Actor substrate |
| Manager Assignment | Human 对 workspace 服务号不可拆分的管理与发布权限 | `service_account_managers` |
| Audience Membership | Human 的消息读取、收件身份、有效区间与 read cursor | `scope_memberships` |
| Notification Preference | Human 在服务号会话中的通知状态 | `scope_notification_settings` |
| Scope | 服务号的专属消息容器 | `scopes` |
| Message | 服务号发送的普通消息 | `scope_messages` |
| Platform Broadcast | 平台运营者提交的全 workspace 持久化发送命令 | `platform_service_account_broadcasts` |
| Broadcast Delivery | 一次平台广播在一个 workspace 的幂等执行状态 | `platform_service_account_broadcast_deliveries` |
| Audit Event | 服务号治理、发送授权、Human causality 与 execution 的审计事实 | `service_account_audit_events` |

### 1.2 核心约束

1. 每个服务号实例归属一个 workspace，并拥有一个具名 Service Actor
   installation、一个作者 member 和一个 `type=service_account` 的消息 scope。
2. Workspace 服务号拥有一个本地实例；每个平台服务号按 all-workspaces
   provisioning policy 为每个 workspace 物化本地实例。
3. 服务号是其消息的 durable author、service principal、routing principal、
   notify principal 与 message-idempotency subject。
4. Human manager 通过管理员 authority 授权服务号发送，并作为 caused-by actor、execution
   actor、Audit actor 与可选署名出现。
5. 收件人 membership 同时提供服务号消息读取、Inbox、read cursor、通知与个人
   会话状态；目录发现使用服务号资料与 workspace 访问权限。
6. `scope_messages` 与 message-owned facts 持有服务号消息内容；Platform
   Broadcast 持有跨 workspace 编排、幂等与恢复事实。
7. 服务号消息使用统一 MessagePlan、MessageSemantics、附件、搜索、reaction、
   Pin 与消息生命周期契约。
8. Message create 在目标 workspace 分配 scope sequence，并进入 active Human
   memberships 的普通 unread accounting。
9. Workspace 服务号的 Message edit 与 withdrawal 保持稳定 message id、
   sequence、Inbox sort key 和 read frontier；平台广播物化 created lifecycle
   message。
10. Canonical message transaction 与 outbox payload 的写入基数与收件人数解耦；
    平台发送通过 bounded asynchronous workspace fanout 扩展。
11. 管理和消息 mutation 记录 typed actor、permission basis、对象版本、
    correlation id 与时间。

## 2. 身份、账号与 Human 管理员

### 2.1 Service Actor 映射

Service Actor Platform 为服务号产品定义共享 target registration。该 definition
使用 `service_kind=service_account`、`slug=service-account`、
`installation_mode=named_multi_instance`，并注册 `message.write`
capability 与 `service_account_message` delivery contract。每个服务号
workspace 实例映射到一个 workspace-scoped 具名 installation：

| Record | 服务号映射 |
| --- | --- |
| `service_definitions` | 平台共享 definition；注册 service kind、installation mode、profile resolver 与 capability contract |
| `platform_service_accounts` | 平台服务号的全局 principal、资料、策略与广播 sequence |
| `service_accounts` | Workspace 服务号 principal/profile authority，或平台服务号的 workspace 本地实例 |
| `platform_service_account_workspace_instances` | 平台服务号 principal 与本地 instance 的生效 binding |
| `service_installations` | 每个本地实例一条具名 installation；`instance_key=service_account.principal_id` |
| `service_members` | 每个 installation 一条 service member；通用 substrate 的 handle/display projection 均镜像服务号单一名称，并提供 author member |
| `service_capabilities` | 共享 definition 上的 `message.write` capability 与 delivery contract |
| `service_grants` | 每个具名 installation 的 live `message.write` grant |
| `service_target_bindings` | installation 将 `message.write` 绑定到自己的消息 scope |

Workspace 服务号使用 `service_accounts.id` 作为 principal。平台服务号使用
`platform_service_accounts.id` 作为跨 workspace 稳定 principal；对应本地
`service_accounts.principal_id` 保存该全局 principal。共享 definition 持有
产品注册和 definition-level capability；具名 installation 将 principal 映射到
workspace；service member 持有作者 member，并将单一名称镜像到通用 Service Actor 展示字段。

Workspace 服务号的资料 authority 为 `service_accounts`。平台服务号的资料
authority 为 `platform_service_accounts`，并按 `profile_version` 同步到
`service_accounts` 与 `service_members` 的 workspace display projection。
`service_account_managers` 持有 workspace 服务号的 Human 管理与发布 authority。

服务号 AuthorProfile 为：

    actorType: service
    serviceKind: service_account
    principalId: serviceAccount.principalId
    memberId: serviceAccount.authorMemberId
    targetId: service-account:{serviceAccount.id}
    displayName: canonicalProfile.displayName
    avatarUrl: canonicalProfile.avatarUrl

名称在同一 workspace 中按 trim 后的大小写无关规则唯一。`targetId` 使用不可变账号
ID 组成的 `service-account:{serviceAccount.id}` typed identity target，其 capability set 为
`profile.open` 与 `conversation.open`。作者导航以当前
`workspace_id + principalId` 解析本地 instance 并打开服务号会话。

平台实例达到 profile-ready 时，workspace binding、local account projection 与
global platform profile 使用相同 profile version；local account、service member
与 current target binding 的名称和头像来自同一 canonical profile。

### 2.2 服务号发送身份与 Human 授权

Workspace 服务号发送命令由服务号 actor 执行。Active
`service_account_managers` row 是 authenticated Human 对管理和发布命令的唯一
permission basis，不存在独立 manage/publish capability。Public message route 解析 `scopeId` 后，由 service-account
target resolver 固定解析以下 actor shape：

| Actor / fact | 值 |
| --- | --- |
| `durable_author` | 服务号 principal + 本地 author member |
| `service_principal` | 服务号 principal + named installation + service member |
| `routing_principal` | 服务号 principal + 本地 author member |
| `notify_principal_member_id` | `service_account.author_member_id` |
| `idempotency_subject_member_id` | `service_account.author_member_id` |
| authorization basis | `service_grant + service_account_manager` assignment |
| `caused_by_actor` | authenticated Human manager |
| `execution_actor` | authenticated Human manager |
| optional `byline_actor_ref` | authenticated Human manager |

Message create command 携带随机 UUID 形式的 `client_message_id`。统一幂等键为
`(scope_id, author_member_id, idempotency_subject_member_id, client_message_id)`，
因此同一服务号的所有 manager 共享服务号发送命名空间。同 key 与 canonical
payload digest 的重试返回同一 message；同 key 与不同 digest 返回 typed
`idempotency_conflict`。

可选 Human 署名由服务端从当前 manager 解析为 `byline_actor_ref`，作为
message-owned presentation metadata 进入 canonical payload digest。消息主作者、
作者导航、routing、notify、permission 与幂等始终使用服务号身份。历史署名通过
retained Human member identity 解析。

服务号消息显示服务号 AuthorProfile。管理台与 Audit 同时显示服务号 actor、
Human authorization、causality、execution 与可选署名。

ContributionSource 使用统一 service direct-post source：

    kind: service_direct_post
    refType: message
    refId: message.id

该 source 描述服务号直接写入普通消息；typed actor facts 与 Audit 表达发送身份和
Human 授权链。

### 2.3 Workspace 创建申请与审批

每次 Workspace 服务号 create command 都创建一个
`service_account_create_request`。Workspace 创建策略为当前 Human 解析
`direct_create` 或 `approval_required`：

- `direct_create` 在同一 canonical transaction 中把 request 置为 authorized，
  执行 Workspace Account create，并以 provisioning request 返回账号 ref；
- `approval_required` 将 request 置为 awaiting authorization，并以请求 id、
  request version 与 payload digest 建立 Approval subject。

`service_account_create_requests` 保存：

- id、workspace_id、requested_by_member_id；
- request_version、client_request_id、payload_snapshot、payload_digest；
- authorization_path、business_state；
- approval_instance_id、consumed_decision_version；
- cancel_client_mutation_id、cancel_payload_digest、cancel_approval_receipt_ref、
  cancel_result_version；
- created_service_account_id、version；
- created_at、updated_at、cancelled_at、fulfilled_at。

`business_state` 使用 `submitted`、`awaiting_authorization`、`authorized`、
`declined`、`cancelled`、`provisioning`、`fulfilled` 与
`action_required`。状态与 request version 一起提供申请列表、申请详情、审批卡片、
重试和 Audit 的 authoritative projection。

`payload_snapshot` 固定名称、简介与头像 asset。每个 create request 是一个 immutable submission，
`request_version` 与 `payload_digest` 在 submit transaction 中确定。需要调整创建
内容时，调用方取消当前请求并以新的 `client_request_id` 提交新请求；新请求建立
独立 Approval subject。Approval subject 使用：

    subject_type: service_account_create_request
    subject_ref: create_request.id
    subject_version: create_request.request_version
    payload_digest: create_request.payload_digest

Approval 域持有审批实例、审批人、状态、决策、理由与版本。内置 Approval
以 App service member 身份，将审批事件通过 App Notification intent 投影为
审批人 DM 中的普通消息或交互卡片。Notification business-object binding 保存
`approval_instance_id` 与 `expected_approval_version`；Human action request 携带
card revision 与 client action id，经
`agentteam.app.notification.action` delivery 进入 Approval handler，再调用
Approval API。

Service Account 域消费 versioned approved decision，校验 request version、
payload digest、workspace membership、当前创建策略和 name claim，再进入同一
Workspace Account create transaction。该 transaction 创建 principal、named
installation、author member、message scope、首位 manager、manager membership
baseline、全员 audience reconcile intent、Audit 与 outbox，
将 `created_service_account_id` 回写到请求，并把 request 置为 provisioning。
Audience reconcile 完成后，account 进入 ready，request 进入 fulfilled。
Declined、cancelled 与 action-required outcome 更新 create request 的业务状态。

账号物化以 create request id 为幂等锚点。Approval 的 reviewer card 以
`(service_account_create_request_id, recipient_member_id)` 形成 stable notification
identity；applicant 另有稳定的 pending receipt 与 terminal result identity。所有投影
把 approval instance 作为 versioned business object ref；
后续 card update 以 notification id、approval object version 与 notification
revision 形成 mutation key，并读取 Approval 域 authoritative state。

Create Request cancel 携带 `expected_version` 与 `client_mutation_id`，适用于
`submitted`、`awaiting_authorization` 与 pre-materialization `action_required`，并
要求 `created_service_account_id IS NULL`。Approval 域以 request、subject version
和 mutation id 关闭 subject，并返回 authoritative closure receipt。Service
Account cancel transaction 保存 closure receipt、cancel mutation id/digest/result
version、request cancelled state，以及一条 App notification/card update intent。
App Notification projector 按 Approval authoritative state 分批幂等更新关联卡片。
同一 mutation id 与 payload digest 在重试中返回同一结果；已有 created account ref
时，后续治理使用账号 profile、manager 或永久删除 API。

### 2.4 平台服务号与 workspace 物化

`platform_service_accounts` 是平台服务号的全局 principal 与管理 authority，
包含：

- id、name、description、avatar_asset_id；
- profile_version、version；
- provisioning_mode=all_workspaces、provisioning_state；
- applied_provisioning_generation；
- audience_policy_version；收件范围固定为 workspace 全部 active Human；
- latest_broadcast_seq；
- created_by_operator_user_id；
- created_at、updated_at。

平台服务号存在时持续拥有资料管理、workspace provisioning、broadcast acceptance
与 delivery 能力。Delete 在 platform root version lock 下先锁定全部本地实例，删除
workspace bindings、本地 account、installation、service member、author member、消息
scope 与消息历史，再释放 name namespace 并删除 platform root；provisioning inputs、
broadcasts、deliveries 与 delivery assets 随 root 级联删除。删除审计在同一事务中先行
写入，账号外键随后置空，而 subject id/version 继续保留被删对象事实。

`service_account_name_namespaces` 为 normalized name 保存 deployment-level
serialization row 与 platform owner ref；
`service_account_name_claims` 保存 workspace-scoped name claims。Workspace
Account create 与 Platform Account create 锁定相同 namespace row，并原子写入相应
claim。账号存在期间持续保留 name claim；永久删除释放 claim，使名称可再次使用。

每个 normalized name namespace 在 deployment 内处于一种 ownership shape：
platform owner，或一个/多个 workspace-scoped claims。Platform Account create 仅在
workspace claim set 为空时写 platform owner；Workspace Account create 仅在
platform owner 为空时写 workspace claim。该互斥保证平台账号可以在每个 workspace
使用相同名称完成本地物化。

`platform_service_account_workspace_instances` 包含：

- platform_service_account_id、workspace_id、local_service_account_id；
- opened_provisioning_generation；
- effective_from_broadcast_seq、effective_to_broadcast_seq；
- last_applied_broadcast_seq；
- applied_profile_version、provisioning_state、version；
- created_at、updated_at。

Platform Account create 与 Workspace create 在同一 deployment-level provisioning
generation boundary 写入 durable input。Reconciler 以 generation、stable cursor
与唯一 `(platform_service_account_id, workspace_id)` binding 将两类输入收敛为
完整 cross-product；新 binding 的 `opened_provisioning_generation` 固定为首次覆盖
该 platform-account/workspace pair 的 input generation。

平台服务号首次启用时，以 bounded reconcile 为每个 workspace 建立 binding、
local account、named installation、service member、`message.write` grant、
target binding、message scope、mandatory membership baseline 与 audience reconcile
intent。Workspace-local audience reconcile 分批物化 Human memberships，使 local
account 进入 audience-ready；全部 local instances 到达 identity-ready 与
audience-ready 后，`applied_provisioning_generation` 到达 deployment generation，
platform `provisioning_state` 进入 ready。

Workspace instance open、close 与 broadcast sequence allocation 共享每个 platform
service account 的 serialization boundary。创建 binding 时读取
`latest_broadcast_seq=n`，设置 `effective_from_broadcast_seq=n+1` 与
`last_applied_broadcast_seq=n`；关闭 binding 时设置
`effective_to_broadcast_seq=latest_broadcast_seq+1`。Interval endpoint 固定每条
broadcast sequence 的 workspace inclusion。Binding 的 opened generation 晚于
已接受且尚未编号 broadcast 的 required generation 时，后续 target enumeration
为这些非收件 sequence 写 generation-excluded cursor settlement，从而保持该 binding 的
`last_applied_broadcast_seq` 连续。

### 2.5 Workspace Instance 资料与删除

`service_accounts` 包含：

- id、principal_id、workspace_id；
- management_kind、platform_service_account_id；
- service_installation_id、service_member_id、author_member_id；
- message_scope_id；
- name、description、avatar_asset_id；
- applied_platform_profile_version；
- audience_policy_version、effective_audience_version、
  audience_state；
- version；
- created_by_member_id、created_by_operator_user_id；
- created_at、updated_at。

`service_accounts.id` 是 workspace-local instance id。
`service_accounts.principal_id` 是 AuthorProfile、account route 与平台跨
workspace 身份使用的 canonical principal。Conversation id 使用
`serviceAccount:{messageScopeId}`；scope identity key 使用
`service_account:{workspaceId}:{principalId}`。

Workspace 服务号创建时使用 `management_kind=workspace` 与
`principal_id=id`。平台实例使用
`management_kind=platform` 与全局 platform principal。两类实例的收件范围都固定为
workspace 全部 active Human。Audience materialization 完成后
`effective_audience_version=audience_policy_version`，实例进入 ready。

Workspace-owned account 的 Delete 要求 workspace owner/admin 或当前 manager，使用
expected account version，并在一个事务中删除 create-request result、账号、manager/name
claim、installation、service member、author member、消息 scope、消息历史、audience/read
state、outbox 与账号头像资产。Platform-owned local account 不能由 workspace 删除，
只随 platform root Delete 一并清除。

### 2.6 Human 管理员

| 主体 | 能力 |
| --- | --- |
| platform operator | 创建与治理平台服务号、管理平台资料与策略、提交全 workspace 广播、查看全局 delivery 审计 |
| workspace owner / admin | 配置创建策略、审批创建申请、治理账号、添加或移除管理员、查看治理审计 |
| service-account manager | 维护管理员名单，并授权和执行服务号消息创建、编辑、撤回以及 shared Pin / top notice 命令 |

Workspace 服务号 Manager Assignment 绑定 active Human member。管理与发布是同一个
不可拆分的 authority，不存在两套角色或 capability。每个 workspace 服务号
至少拥有一个 manager；创建者或申请人在账号 transaction 中自动成为首位 manager。

Workspace Human deactivation 会触发其 Service Account manager assignment 与 audience
membership 的治理更新。管理员转移维持账号至少一位 manager 的不变量。

## 3. 收件范围与 Scope Membership

### 3.1 固定全员 Audience

服务号收件范围固定为 workspace 内全部 active Human members，不存在 audience mode、
selected set、opt-in、订阅或退订。Workspace Human lifecycle projector 与 bounded
audience reconciler 是唯一 membership 变更来源；服务号管理员变更不改变收件资格。

服务号目录对 workspace 内 active Human 展示账号 profile。服务号消息 history、
archive、permalink、search、attachment 与 reaction 读取要求当前
`scope_membership`，并以 `direct_membership` 进入 shared SQL readable predicate。

Audience reconcile 建立或关闭服务号 message scope 的 `scope_memberships`。Membership 同时提供：

- message history 与 message-owned facts 读取；
- Inbox candidate；
- `last_read_seq` 与 manual unread；
- `scope_notification_settings`；
- personal conversation pin、hide 与 restore；
- UnreadRuntime roster eligibility。

管理员与普通 Human 使用相同的收件 membership。添加或移除管理员只改变管理与发布
authority；只要该 Human 仍为 workspace active Human，就继续正常收件。

### 3.2 Membership 基线与生命周期

新收件人 membership 在 scope lock 下使用：

    effective_from_seq = scope.latest_seq + 1
    last_read_seq = scope.latest_seq

当前 membership 授予服务号完整历史读取；`effective_from_seq` 与
`last_read_seq` 控制加入后的 attention window，使既有消息可读并保持已读。
Audience 移除或 workspace Human deactivation 关闭当前 membership interval，
同时结束 Inbox、notification 与 read mutation authority。

Workspace Human reactivation 由全员 audience projector 自动恢复 membership。每个
membership open/close 都与 `scope.latest_seq`、roster generation 和 Audit 使用同一
scope serialization boundary。

### 3.3 Audience Version 与 Runtime Roster

Workspace Human lifecycle 与服务号实例创建推进 `audience_policy_version`。Bounded reconcile 使用
member cursor、policy version 与 resumable checkpoint 收敛
`scope_memberships`；完成时推进 `effective_audience_version` 并令
`audience_state=ready`。

每个改变 message attention eligibility 的 mutation 单调推进
`scope.roster_generation`。Message create 捕获
`required_roster_generation=scope.roster_generation`；UnreadRuntime 在 complete
roster 到达该 generation 后执行 attention accounting。

## 4. 服务号会话与普通消息

### 4.1 Scope Capability Registry

每个服务号实例拥有一个 `scopes.type=service_account` 的消息 scope。全表唯一
identity key 为 `service_account:{workspaceId}:{principalId}`。Scope capability
registry 为 `service_account` 注册：

| Capability | Authority |
| --- | --- |
| 服务号 message read | active direct membership |
| Workspace Service Account Message create | management_kind=workspace + account exists + service_grant + service_account_manager + audience ready |
| Platform Broadcast delivery | management_kind=platform + platform source exists/ready + service_grant + platform_service_account_delivery + audience ready |
| Workspace Message edit / withdrawal | management_kind=workspace + account exists + service grant + manager basis + durable author + expected message version |
| Workspace Attachment upload / claim | management_kind=workspace + account exists + service grant + manager basis + durable author |
| Platform Broadcast asset materialize / claim | platform delivery basis + service grant + local durable author |
| Reaction | account exists + authenticated Human + target direct membership |
| Read cursor / manual unread | active direct membership |
| Personal notification / pin / hide | active direct membership |
| Workspace shared message Pin / top notice | workspace account exists + manager + target message read |

Generic MessagePlan writer 读取 capability registry。服务号会话的 content authority
由 `scope_messages` 与 message-owned facts 持有。

### 4.2 Workspace Service Account Direct-Send Target

Human manager 向统一 message API 提交服务号 create command 时，resolver 返回：

| Target role | 值 |
| --- | --- |
| Requested target | `scope:{messageScopeId}` |
| Identity target | `service-account:{serviceAccount.id}` |
| StorageScope / DeliveryScope / ReadScope | `message_scope_id` |
| durable_author | service-account principal + local author member |
| service_principal | principal + installation + service member |
| routing_principal | service-account principal + local author member |
| caused_by_actor | authenticated Human manager |
| execution_actor | authenticated Human manager |
| notify_principal | local service-account author member |
| idempotency subject | local service-account author member |
| PermissionBasis | service_grant + service_account_manager |

Attachment claim ownership 使用 durable author。Unread、browser push 与
self-notification exclusion 使用 local service author；该 member 位于 Human
audience roster 之外，因此所有 active Human memberships（包括 manager）使用相同
attention 规则。Manager 在发送后需要立即已读时，客户端提交普通 read-cursor
action。

### 4.3 Message Content 与 Semantics

服务号消息使用统一 MessagePlan：

- `message_type` 使用 MessageSemantics registry 中已注册的 Human-visible kind；
- content 使用消息域 canonical content；
- attachments 使用统一 upload、claim、scan、download 与 reader authorization；
- mentions、source refs、reaction、Pin、top notice、permalink、search 与 moderation
  使用消息域契约；
- 可选 `byline_actor_ref` 作为 message-owned presentation metadata；
- message id、scope sequence、timestamps、edit revision 与 lifecycle state 使用
  `scope_messages` authority。

服务号发布统一写 `service_account_post` message semantics；metadata 中的
`serviceAccountPost.title` 与正文组成可点击预览卡片，点击后展示完整 Markdown。
消息流 renderer、Inbox preview、history 与 search 使用同一 MessageSemantics
descriptor。普通 Human、Agent 或 App writer 不得写入该受限消息类型。

### 4.4 Workspace Message Create

Message create transaction 原子写入：

- 一个服务号 `scope_message`；
- message-owned attachments、source refs 与可选 byline；
- 对应 search document；
- scope counters；
- 一个 recipient-count-independent `scope_fanout_outbox` intent；
- service-account Audit event。

Audit event 保存服务号 durable author、service/routing/notify/idempotency subjects，
Human manager assignment basis、caused-by actor、execution actor、可选 byline、
message id/version、correlation id 与时间。

Transaction commit 后，统一 delivery runtime 处理 realtime、UnreadRuntime 与
browser notification。MessageStored 使用 active membership roster、
notification setting、notify principal、required roster generation 与 scope
generation 进入普通 unread accounting。

### 4.5 平台全 workspace 广播

Authenticated platform operator 通过
`POST /api/admin/platform-service-accounts/:platformServiceAccountId/broadcasts`
提交一次平台广播。请求包含 `client_broadcast_id` 与统一 MessagePlan 所需的
canonical content、message type、ordered attachments、source refs 和 client-owned
metadata。API 在 durable acceptance 后返回 `202 Accepted`、broadcast id、
当前 state、状态 URL 与 optional broadcast sequence；provisioning fence 完成并分配
sequence 后，status surface 返回该 sequence。

Broadcast acceptance transaction：

1. 校验 platform account 存在且 operator authority 有效；
2. 在 Human-origin moderation boundary 校验 canonical MessagePlan；
3. 在 deployment provisioning generation boundary 捕获
   `required_provisioning_generation=G`，并在 platform-account source boundary
   分配单调 `acceptance_ordinal`；
4. 保存 immutable MessagePlan snapshot、payload digest、operator principal、
   client id、correlation id 与 source policy version；
5. 保存 waiting-provisioning state、Audit 与 allocator wake outbox。

Broadcast sequence-allocation transaction：

1. 在 platform-account source lock 下选择最小尚未编号的
   `acceptance_ordinal`；
2. 重新校验 platform account/version 与
   `applied_provisioning_generation>=G`；
3. 为该 broadcast 分配单调 `broadcast_seq` 并更新 accepted state；
4. 写入携带 G、broadcast sequence 与 immutable snapshot ref 的 bounded
   target-enumeration outbox intent。

账号永久删除与 broadcast allocator/dispatcher 共享 platform root row lock。删除事务
级联移除尚未编号和已编号 broadcasts、deliveries 与 assets，因此删除提交后不存在
可恢复的 paused/archived broadcast 状态。

Broadcast 接受幂等键为
`(platform_service_account_id, operator_principal_id, client_broadcast_id)`。同
key 与相同 digest 返回已有 broadcast；同 key 与不同 digest 返回 typed conflict。

一次 `broadcast_seq` 的 target set 由 workspace-instance interval 固定：

    opened_provisioning_generation <= required_provisioning_generation
    AND
    effective_from_broadcast_seq <= broadcast_seq
    AND (effective_to_broadcast_seq IS NULL
         OR broadcast_seq < effective_to_broadcast_seq)

Captured G 是 acceptance-time workspace target fence。G 之后创建的 workspace
binding 即使在最终 sequence allocation 前完成，也从本次 target set 排除，并从其
后续生效 broadcast sequence 开始接收消息。

Target enumerator 要求 source applied generation 已达到 broadcast 的 required G，
再按 workspace id 稳定分页扫描 interval 包含该 sequence 的 bindings：

- `opened_provisioning_generation<=G` 的 binding 创建普通 delivery target；
- `opened_provisioning_generation>G` 的 binding 创建
  `recipient_eligible=false`、typed outcome=`generation_excluded` 的 cursor-only
  settlement。

两类 row 都写入 `platform_service_account_broadcast_deliveries`，记录 workspace、
local account、broadcast sequence、recipient eligibility、state、attempt、lease、
placement epoch、local message ref、typed outcome 与 CAS version。
`UNIQUE(broadcast_id, workspace_id)` 保证枚举幂等。Generation-excluded settlement
通过同一 per-workspace sequence/settlement fence 推进
`last_applied_broadcast_seq`，并保持 local message ref 为空；它不进入 recipient
target counts、delivery attempts 或 exception counts。

Delivery state machine 使用 `queued`、`leased`、`waiting_instance`、
`waiting_audience`、`retry_wait`、`operator_attention`、`delivered`、
`closed` 与 `skipped`。Dispatcher 通过 expected version 获取 bounded lease；
lease token 与 placement epoch fence message transaction 和 settlement。
Generation-excluded row 以 closed/cursor-only settlement 完成，并在后续 eligible
sequence 开始前提供连续的 workspace cursor。

Workspace MessagePlan transaction 在同一数据库事务中锁定 delivery 与 workspace
placement rows，校验 delivery version、lease token/expiry、placement epoch 与
unsettled state，再提交 delivery-asset mappings、attachments、message、outbox 与
delivered settlement。Settle-skip 使用相同 execution fence；确定性 message key
已经存在时收敛为 delivered，message 尚未存在时写 skipped/Audit 并推进
`last_applied_broadcast_seq`。

Central dispatcher 按 current workspace placement 发送 authenticated internal
execute command。Workspace handler 校验 `ManagedWorkspaceSet` ownership 与
placement epoch，解析 local account、installation、service member、grant、binding 与
audience ready，再通过普通 MessagePlan writer 写入本地服务号
会话。该路径使用 [`scope-model.md`](../message/scope-model.md) 定义的
`autonomous_store_recoverable` policy。Transaction 同时把
`RecoverableStreamProjection` 固化到 fanout outbox；
app Store 在 transaction 内保留完整 fresh `MessageDelivery`，只在 commit
成功后交给 workspace-local shared `DeliveryFanout`，按普通消息顺序
应用 Human unread、`message.created`/browser projection，并在成功后完成
outbox。PlatformService 拥有 broadcast lease/orchestration，它只调用 app Store
writer，不再拥有独立 message fanout callback。该首次 fanout 只接受本次
新提交且带完整 AppMessage 的 delivery；幂等 replay、失败事务和不完整结果
不得重复投影。若 commit 后、首次 fanout 前进程退出，outbox replay
可用稳定 event id 恢复 stream projection，但普通 scope roster 未冻结，因此不承诺
精确恢复该 crash window 的 unread accounting。

Broadcast attachments 使用 immutable platform asset manifest。Canonical digest
覆盖 ordered asset ref、content hash、media type、size 与 client label。每个
workspace transaction 原子写入
`(delivery_id, asset_ordinal)` mapping、workspace attachment、local service-author
claim、scope message 与 attachment refs；目标 message 的 direct membership 继续
授权 attachment 读取。

平台 delivery actor 与幂等 shape 为：

| Target role | 值 |
| --- | --- |
| durable_author | platform service-account principal + local author member |
| service_principal | platform principal + local installation + local service member |
| routing_principal | platform service-account principal + local author member |
| caused_by_actor | authenticated platform operator |
| execution_actor | trusted platform broadcast delivery service |
| notify_principal | local service-account author member |
| PermissionBasis | service_grant + platform_service_account_delivery |
| client_message_id | `platform-broadcast:{broadcastId}` |
| idempotency subject | local service-account author member |

每个 workspace 分别获得 message id、scope sequence、search document、Audit、
outbox、首次 post-commit UnreadRuntime accounting 与 realtime projection。
Deterministic client id
与统一四元 message key 使 execute/settlement response 丢失后的重试返回同一
message。

同一 platform service account/workspace 按 broadcast sequence 顺序执行。
`delivered`、`closed` 与 `skipped` 推进 workspace cursor；
`retry_wait` 与 `operator_attention` 保持当前 sequence。Broadcast 状态由
target ledger 聚合为 `waiting_provisioning`、`accepted`、`dispatching`、`completed`、
`completed_with_exceptions` 或 `closed`。

### 4.6 Workspace Message Edit 与 Withdrawal

Workspace Message edit 使用 expected edit revision，更新 content、message-owned
facts、search document、edited-at/execution actor、Audit 与 outbox。Message id、
scope sequence、Inbox sort key 与 read frontier 保持稳定。

Workspace Message withdrawal 使用统一 lifecycle tombstone，记录 manager assignment
basis、Human cause/execution actor、reason、message version、Audit 与 outbox。
History、permalink、search、Pin、reaction 与 moderation 读取统一 lifecycle
projection。更正消息使用新的 Message create。

## 5. Inbox、已读未读、通知与搜索

### 5.1 Inbox View Model

Active Human membership 在其 interval 内出现首条服务号消息后拥有
`serviceAccount` conversation candidate：

    conversationId: serviceAccount:{messageScopeId}
    kind: serviceAccount
    scopeId: messageScopeId
    accountId: serviceAccountPrincipalId
    route: /inbox/service-accounts/{accountId}

Conversation registry 解析账号、message scope 与 current membership。Inbox row
是以下权威事实的 joined view：

| 字段 | 来源 |
| --- | --- |
| 名称、头像 | management-kind profile resolver + local instance |
| 最新消息 preview、sort time | membership attention window 内的 latest scope message |
| participation、read cursor | `scope_memberships` |
| notification state | `scope_notification_settings` |
| pin、hide、manual unread | `conversation_member_states` |
| unread state | UnreadRuntime |

Account、membership、scope tail、read-state、notification 与 personal-state events
按 conversation id 触发 realtime invalidation，并推进 cache generation。

### 5.2 Read Cursor

服务号会话 unread 使用 `scope_memberships.last_read_seq`。打开 Inbox row、
会话根路由或 message permalink 时，普通 viewport/read API 将 cursor 单调推进到
最高已呈现 message sequence。

`POST /api/v1/workspaces/:workspaceId/conversations/:conversationId/actions`
支持 `serviceAccount:{messageScopeId}` 的 `mark_read`、`mark_unread`、
`mute`、`unmute`、`pin`、`unpin`、`hide` 与 `restore`。Personal
pin 使用 `conversation_member_states`；shared message Pin 使用 Message Pin API。

显式 multi-conversation mark-read 使用 bounded batch API，接收唯一 conversation
ids 与 `readThroughSeq`，并逐项执行统一 cursor action。每次 cursor commit
生成 ReadCursorAdvanced、UnreadRuntime delta、conversation cache update 与当前
Human 的 realtime update。

### 5.3 Notification、Reaction 与 Pin

Notification 使用 `scope_notification_settings` 的 `active`、`quiet` 与
`mute`。Message create 产生 MessageStored event。UnreadRuntime 以 active
membership roster、membership interval、notification state 与 local service-author
notify principal 计算 attention。全部 active Human recipients 使用普通 unread、
browser push 与 realtime message projection。

Reaction 复用 `scope_message_reactions` 与 direct membership readable predicate。
Personal pin、hide 与 restore 复用 `conversation_member_states`。Workspace 服务号
的 Shared Pin 与 top notice 复用 Message Pin contract，并由 manager
authority 管理。

### 5.4 搜索、目录与路由

Active Human membership 通过统一 message search 搜索服务号会话中的 message
content 与 attachment label。搜索复用 `scope_message_search_docs`、readiness、
candidate budget、stable cursor 与 direct-membership visible-row mapper。

服务号目录按名称与简介提供 workspace-aware profile search。目录 discovery
返回 profile 与固定全员 audience 状态；message archive route 在 membership 生效后
返回 scope messages。

路由为：

- Inbox/search result：
  `/inbox/service-accounts/{accountId}/messages/{messageId}`；
- Apps 内的服务号 profile：`/apps/service-accounts/{accountId}`；
- Author navigation：`/apps/service-accounts/{accountId}`。

Workspace route 中的 `accountId` 使用 `service_account.principal_id`。
Resolver 以 `workspace_id + principal_id` 定位本地 instance。

## 6. 权限与 API

### 6.1 Permission Basis

| Action | Permission basis |
| --- | --- |
| 提交 workspace 服务号创建申请 | active workspace Human + workspace creation policy |
| 直接创建 workspace 服务号 | workspace owner/admin 或 policy-authorized creator |
| 审批创建申请 | Approval policy 解析出的 workspace approver |
| 管理 workspace 服务号资料与管理员 | service-account manager 或 workspace governance |
| 添加或移除 manager | service-account manager 或 workspace owner/admin；账号至少保留一位 |
| 永久删除 workspace 服务号 | service-account manager 或 workspace owner/admin + expected account version |
| 创建与管理平台服务号 | platform operator |
| 永久删除平台服务号 | platform operator + expected root version |
| 提交平台全 workspace 广播 | platform operator + platform account exists/ready |
| 执行平台 workspace delivery | platform delivery basis + service grant + local account exists + audience ready |
| Workspace 服务号发送消息 | manager assignment + service grant + account exists + audience ready |
| 编辑、撤回 workspace 服务号消息 | workspace account + manager assignment + service grant + target message authority |
| 管理 workspace shared Pin / top notice | workspace account + manager assignment + target message read |
| 读取 history、archive、permalink、search 与 attachment | active direct membership |
| 更新 read cursor、notification 与 personal state | active direct membership + authenticated Human self |
| 添加与移除 reaction | account exists + active direct membership + authenticated Human self |

### 6.2 API Surface

Workspace 服务号 management routes 位于
`/api/v1/workspaces/:workspaceId`：

| Resource family | Surface |
| --- | --- |
| Create Requests | submit、detail、list、cancel |
| Service Accounts | list、detail、profile、permanent delete |
| Managers | list、add、remove |
| Audience | 固定全员 membership 状态与 reconcile 进度（无 mutation API） |
| Messages | archive、history、message permalink、cursor |
| Audit | governance、authorization、message execution events |

Create Request submit 返回 request id、request version、authorization path、
business state、approval ref 与 optional created account ref。Create Request
cancel 接收 `expected_version` 与 `client_mutation_id`，返回 authoritative request
state/version、Approval closure receipt 与 Approval ref。Cancel policy 要求 request
处于 authorization-pending pre-materialization state；已有 created account ref 时
返回 typed `create_request_already_materialized` result，并提供 account
resource ref。Direct-create path
可以在首次响应中返回 provisioning account；audience reconcile 完成后 request 与
account 分别进入 fulfilled/ready。Approval path 的 approve/reject action
使用 Approval API，Approval card 复用同一 API。Approved decision 由 Service
Account domain event consumer 幂等物化账号。

服务号发送、编辑、撤回、附件、shared Pin 与 top notice 使用统一 message API 和
service-account scope resolver。Reaction、personal state、history、search 与 read
actions 使用统一 message contract。Create 使用 service-author-scoped client id；
edit 使用 expected edit revision；其它 mutation 使用所属 contract 的 version、
claim、unique key、sidecar revision 或 monotonic cursor precondition。

平台 routes 位于 `/api/v1/admin/platform-service-accounts`，包含 account
list/create/detail/profile/permanent-delete、provisioning、broadcast
create/detail/list、target counts、delivery retry、settle-skip 与 bounded
diagnostics。

Central dispatcher 通过 authenticated
`POST /internal/workspaces/:workspaceId/platform-service-account-deliveries/:deliveryId/execute`
调用 owning workspace process。Request 携带 delivery version、lease token、
placement epoch 与 snapshot digest。

所有 list surface 使用 opaque cursor、limit 和稳定排序 tuple。

## 7. 存储、一致性与成本

### 7.1 Domain Tables

| 表 | 所有权 |
| --- | --- |
| `service_account_create_requests` | Workspace 创建意图、authorization path、Approval ref 与物化结果 |
| `service_account_name_namespaces` | Normalized name 的 deployment serialization row 与 platform owner |
| `service_account_name_claims` | Workspace 服务号 name claim |
| `platform_service_account_provisioning_inputs` | Platform Account create 与 Workspace create 的 cross-product generation input |
| `platform_service_accounts` | 平台 principal、资料、策略与 broadcast sequence |
| `platform_service_account_workspace_instances` | 平台账号到 workspace 实例的 interval、profile version 与 delivery cursor |
| `platform_service_account_broadcasts` | 平台广播命令、immutable MessagePlan、幂等与聚合状态 |
| `platform_service_account_broadcast_deliveries` | Per-workspace target、执行、恢复与 local message ref |
| `platform_service_account_delivery_assets` | Delivery asset ordinal 到 local attachment/claim 的幂等映射 |
| `service_accounts` | Workspace instance、principal ref、audience policy 与 Service Actor refs |
| `service_account_managers` | Workspace 服务号 Human 管理与发布 authority |
| `service_account_audit_events` | 治理、发送 authorization、causality 与 execution Audit |

Service Actor、scope、message、attachment、source、search、reaction、Pin、
membership、notification 与 conversation member state 使用各自通用 domain
tables。

### 7.2 关键约束

- `UNIQUE(workspace_id, requested_by_member_id, client_request_id)` on create
  requests；
- create request 的 Approval subject version/digest 等于 current request
  version/digest；
- create request 的 payload snapshot、request version 与 payload digest 在 submit
  后保持 immutable；
- `UNIQUE(workspace_id, requested_by_member_id, cancel_client_mutation_id)` on
  non-null create request cancel receipts；
- `UNIQUE(created_service_account_id)` on non-null create request results；
- `PRIMARY KEY(service_accounts.id)`；
- `PRIMARY KEY(platform_service_accounts.id)`；
- `PRIMARY KEY(service_account_name_namespaces.normalized_name)`；
- `UNIQUE(workspace_id, normalized_name)` on workspace name claims；
- normalized name namespace 的 platform owner 与 workspace claim set 互斥，并
  通过同一 namespace row 串行；
- `UNIQUE(workspace_id, principal_id)`；
- `UNIQUE(platform_service_account_id, workspace_id)` on workspace instances；
- `UNIQUE(local_service_account_id)` on workspace instances；
- `UNIQUE(message_scope_id)`、`UNIQUE(service_installation_id)`、
  `UNIQUE(service_member_id)` 与 `UNIQUE(author_member_id)`；
- named installation 的
  `UNIQUE(service_definition_id, workspace_id, instance_key)`，其中
  `instance_key=service_account.principal_id`；
- message scope 的 workspace、type 与 identity key 对应 local account；
- target binding 的 workspace、definition、installation、member、target ref 与
  message scope 对应同一 account；
- workspace account 至少拥有一个 manager；
- audience ready 时
  `effective_audience_version=audience_policy_version`；
- current Human audience facts 使用 local message scope 的 active
  `scope_memberships`；
- workspace service-account message 满足
  `author_member_id=notify_principal_member_id=idempotency_subject_member_id=service_account.author_member_id`
  且 `author_type=service`；
- platform delivery message 使用 local service-account author member 作为
  author、notify 与 idempotency subject；
- `UNIQUE(platform_service_account_id, broadcast_seq)`；
- `UNIQUE(platform_service_account_id, acceptance_ordinal)`，sequence allocator 按
  ordinal head-of-line 分配；
- `UNIQUE(platform_service_account_id, operator_principal_id, client_broadcast_id)`；
- broadcast sequence allocation 要求
  `platform_service_account.applied_provisioning_generation>=broadcast.required_provisioning_generation`；
- broadcast target binding 满足
  `opened_provisioning_generation<=required_provisioning_generation`；
- `UNIQUE(broadcast_id, workspace_id)`；
- generation-excluded delivery 的 `recipient_eligible=false`、local message ref 为空，
  并通过 per-workspace settlement fence 推进 `last_applied_broadcast_seq`；
- `UNIQUE(delivery_id, asset_ordinal)`；
- delivery lease、placement epoch、local message ref 与 workspace sequence cursor
  使用同一 execution fence；
- 所有长生命周期 ID 使用统一 prefix_14-char-base36 contract。

### 7.3 Transaction Boundaries

| Mutation | 原子事实集合 |
| --- | --- |
| Direct create request | request snapshot/digest/version、direct authorization basis、Workspace Account create facts、provisioning account ref、Audit、outbox |
| Approval-required request submit | request snapshot/digest/version、Approval subject ref、awaiting-authorization state、Audit、outbox |
| Create request cancel | request expected version、pre-materialization fence、client mutation id/digest/result、Approval closure receipt、cancelled state、单个 App notification/card update intent、Audit、outbox |
| Approval decision consume | request expected version/digest、approval decision version、business state、create idempotency intent、Audit |
| Workspace Account create | name claim、definition ref、named installation、service member、grant、local account、message scope、首位 manager、manager membership baseline、全员 audience reconcile intent、target binding、Audit、outbox、provisioning request ref |
| Platform Account create | name namespace owner、platform account、profile/audience version、provisioning input、initial fence、Audit、outbox |
| Workspace create hook | Workspace、provisioning generation input、platform-instance reconcile intent |
| Platform workspace provision | binding、local account、installation、member、grant、message scope、mandatory membership baseline、audience reconcile intent、target binding、Audit、outbox |
| Platform Broadcast accept | required generation、immutable MessagePlan、digest、operator actor、waiting-provisioning state、Audit、outbox |
| Platform Broadcast sequence allocation | applied-generation fence、account version、acceptance-ordinal head、source lock、broadcast sequence、target-enumeration intent、Audit |
| Platform target materialize | fixed binding interval/generation cut、recipient deliveries、generation-excluded cursor settlements、enumeration cursor、aggregate version |
| Platform workspace delivery | delivery + placement locks、lease/version/epoch fence、assets、attachments、message、search、scope counters、Audit、outbox、delivered settlement |
| Platform delivery settlement | delivery execution fence、deterministic message lookup、typed outcome、local message ref、workspace sequence cursor、Audit |
| Workspace profile | account profile、service-member projection、Audit、outbox |
| Workspace Account delete | expected version、manager/governance authority、create request、账号及专属 actor/scope/message substrate、Audit |
| Platform profile | platform profile/policy version、provisioning operation、instance projections、Audit、outbox |
| Platform Account delete | expected root version、全部 workspace instances 与本地 actor/scope/message substrate、name namespace、broadcast state、Audit |
| Manager / Human lifecycle | manager assignments、全员 audience membership changes、manager invariant、roster generation、Audit、outbox |
| Audience reconcile batch | expected audience version、bounded membership open/close rows、member cursor、roster generation、Audit、outbox |
| Audience reconcile complete | effective audience version、account ready、optional create request fulfilled、platform instance readiness、Audit、outbox |
| Notification | notification setting、roster generation、Audit、outbox |
| Read / personal state | read cursor、manual unread、pin、hide、runtime event、Audit |
| Message create | MessagePlan、scope message、attachments/sources/byline、search doc、scope counters、Audit、outbox |
| Message edit / withdrawal | message version/lifecycle、message-owned facts、search doc、Audit、outbox |

### 7.4 成本与恢复

Workspace direct account create 的 canonical transaction 写入固定数量 identity、
manager 与 scope rows；audience reconcile 以 bounded batch 物化 Human memberships。
Platform Account create 的 acceptance 为 O(1)，workspace provisioning 为 O(W)。
Message create 与 edit/withdrawal 的 canonical transaction 为 O(1) rows。

UnreadRuntime 使用 scope sequence、membership interval、notification setting 与
read cursor 作为 durable anchors。Audience reconcile 成本为 O(changed members)，
使用 stable member cursor、policy version 与 resumable checkpoint。

一次平台广播产生 O(W) target ledgers 与 O(W) workspace-local message
transactions。Target enumeration 与 delivery 使用 bounded batch、stable cursor、
per-target lease、placement routing 与 workspace-local idempotency。每个本地
message transaction 的 durable row count 与 audience size 解耦。

## 8. UI、Events 与 Audit

### 8.1 UI

Workspace 的 Apps 二级导航包含 Service accounts 分区：分区内提供服务端搜索、稳定
分页、创建入口和账号列表，点击账号后右侧主内容区只显示该账号详情，与 App 的
导航—详情模式一致；不再提供独立的 Settings 服务号目录或兼容路由。普通 reader
的服务号 profile 只展示头像、名称、简介和进入消息流的操作，不展示 manager
名单、Audience 状态、策略版本或其它治理信息。固定 Workspace 全员收件属于运行时
不变量，不提供订阅、退订或 audience 配置 action，也不作为单独的 reader 界面区块。

Inbox 使用普通 conversation list 与只读服务号消息流。消息流使用普通消息列表、日期分组、
未读分隔线、reaction、Pin、附件与 cursor pagination；不内嵌 composer。Workspace
manager 的消息流入口统一命名为 Publish；platform broadcast 使用平台发布入口。
发布界面显示服务号 AuthorProfile、
标题、正文和实时卡片预览，避免管理、阅读与发布操作混杂，并可选择
展示当前 manager 署名。

服务号文章 Reader 复用任务 Detail 使用的标准 `PageModal` 尺寸与交互，不维护独立的
宽度或展开状态。文章标题使用标准 Header；服务号头像、身份 Badge、发布时间与预计
阅读时间位于正文顶部，正文保持约 `76ch` 的有界阅读列并始终完整展开、连续滚动。
已投递文章的 Header 在关闭按钮前提供 canonical message link 复制操作；编辑器预览不
显示无效链接操作。

Workspace 创建入口按策略呈现直接创建结果或创建申请状态。Pending request 显示
Approval instance state；Approval 在 approver DM 中展示普通消息或交互
卡片，决策后将卡片更新为 authoritative final state。处于
`awaiting_authorization` 的创建申请同时显示在 Apps 的服务号分区；二级导航保留
“审批中”状态 Badge，Marketplace collection card 不重复展示审批状态，点击后进入
只读申请详情。申请尚未物化为账号时不可进入服务号详情。Workspace owner/admin
可见当前 workspace 的申请，普通成员只可见自己提交的申请。

具备管理权限的 Manager 或 workspace owner/admin 在同一 profile 额外看到 Manager
名单、头像编辑、搜索添加与逐行移除；这些控件和成员身份不向普通 reader 呈现。
界面不重复展示“Manager 可以管理和发布”、固定全员 Audience 等由权限和产品模型
已经表达的说明性文案。Platform operator console 提供平台服务号 list/create、
Profile、永久删除、Provisioning、Broadcasts、target counts、
delivery diagnostics 与 Audit。

### 8.2 Events 与 Audit

Service Account events：

- `service_account.create_request.submitted`；
- `service_account.create_request.authorized`；
- `service_account.create_request.declined`；
- `service_account.create_request.cancelled`；
- `service_account.created`；
- `service_account.updated`；
- `service_account.deleted`；
- `service_account.manager_changed`；
- `service_account.audience_changed`。

Platform Service Account events：

- `platform_service_account.created`；
- `platform_service_account.updated`；
- `platform_service_account.deleted`；
- `platform_service_account.instance_changed`；
- `platform_service_account.broadcast_accepted`；
- `platform_service_account.broadcast_completed`；
- `platform_service_account.broadcast_delivery_changed`。

Message、reaction、Pin、read-state、search 与 attention events 使用统一
message-domain event contract。Outbox projector 以 event ref、object version 与
correlation id 幂等发送。

Workspace Audit event 记录 workspace、service-account principal/local instance、
action、message id/version、durable author、service/routing/notify/idempotency
subjects、Human manager permission basis、caused-by actor、execution actor、optional
byline、before/after digest、comment、correlation id 与时间。

Create Request Audit 记录 request id/version/digest、requester、authorization path、
Approval ref/decision version、created account ref 与 business state。Platform
Broadcast Audit 记录 platform account、broadcast id/sequence、operator、permission
basis、client id、payload digest、target counts、state/version 与时间。

## 9. 验收标准

### 9.1 身份、创建与审批

- 同一 workspace 的多个服务号共享一个 service-account definition，并拥有独立
  principal、installation、member、grant、binding 与 message scope。
- 服务号 AuthorProfile 在消息、Inbox、作者导航、permalink 与 Audit 中保持一致。
- Workspace direct-send 的 author、routing、notify 与 message idempotency subject
  解析为同一本地服务号 identity；Human manager 解析为 permission basis、
  caused-by/execution actor 与 optional byline。
- 同一服务号的不同 manager 使用同一个 client-message-id namespace。
- Create request 将完整 payload snapshot、version 与 digest 绑定到 Approval subject。
- Create request cancel 以 expected version 与 client mutation id 保存 Approval
  closure receipt 和单个更新 intent；App Notification projector 按 Approval
  authoritative state 分批幂等更新关联审批通知。
- Create request cancel 的授权状态集合为尚未物化账号的
  authorization-pending request；created account ref 对应 account resource ref。
- Approval 将 approval event 物化为普通 DM message/card，并通过 Approval API
  提交带 expected version 的 action。
- Applicant 在提交后立即收到无 action 的 pending DM 回执；approved/rejected 时旧
  回执收敛为终态，并另发一条新结果消息以产生正常 Inbox 未读。两次投递各自幂等。
- Approved decision 幂等进入 canonical Workspace Account create transaction，并
  将唯一 created account ref 回写 create request。
- Workspace 与 platform Delete 都使用 expected version，永久移除账号专属 identity、
  scope、message、audience/read 与编排数据；删除 Audit 保留 subject id/version。

### 9.2 Membership、普通消息与 Inbox

- 固定全员 audience 最终收敛为服务号 scope 的全部 active Human memberships。
- Directory profile discovery 与 message read authority 分别使用 workspace access
  和 current direct membership。
- History、archive、permalink、search、attachment 与 reaction read-check 使用同一
  direct-membership visible-row mapper。
- `scope_memberships` 持有 read cursor 与 attention interval；
  `scope_notification_settings` 持有 notification state；
  `conversation_member_states` 持有 personal pin、hide 与 manual unread。
- 新 membership 以当前 scope tail 作为 unread baseline，同时获得完整服务号历史。
- Message create 只写一个 ordinary scope message、一个 search document、一个
  outbox intent 与一个 Audit event。
- Manager 和其他 active Human memberships 使用同一 unread、push 与 realtime
  attention contract。
- Short text、rich text、media 与 attachment 都使用普通 MessageSemantics；
  服务号域持有发送身份与治理事实。
- Message edit/withdrawal 保持原 message id、sequence、Inbox sort key 与 read
  frontier。

### 9.3 平台服务号与全 workspace 广播

- Deployment 动态支持零到多个平台服务号，每个账号拥有独立 principal、name、
  profile、workspace bindings、broadcast sequence 与 Audit。
- Platform Account create 与 Workspace create 写入同一 provisioning generation
  input，并收敛完整 platform-account/workspace cross-product。
- 每个目标 workspace 物化 local account、installation、member、grant、binding、
  message scope 与 audience memberships。
- Broadcast acceptance 固定 immutable MessagePlan、target generation、idempotency
  digest 与 operator actor；generation fence 完成后固定 sequence。
- Broadcast sequence 只在 applied provisioning generation 到达 captured target
  generation 后按 acceptance ordinal head-of-line 分配，target enumerator 使用同一
  generation fence。
- Broadcast target set 只包含在 captured generation 内打开且 sequence interval
  生效的 workspace bindings；后建 workspace 从后续 broadcast 开始收件。
- Interval 已打开但 generation 晚于 captured fence 的 workspace 获得
  generation-excluded cursor settlement，使后续 eligible broadcast 按连续 sequence
  执行，同时保持本次 recipient target counts 不变。
- Platform Delete 与 allocator/dispatcher 共享 root lock，并级联移除全部 pending 与
  completed broadcast 编排数据以及 workspace-local messages。
- Workspace-instance interval 固定每个 broadcast sequence 的 target set。
- 每个目标 workspace 产生独立 message id、scope sequence、attachment claim、
  search document、permalink、Audit 与 delivery outcome。
- Delivery lease、version、placement epoch 与 settlement 形成同一 execution fence。
- Deterministic client id 与 local service-author idempotency subject 使所有重试
  收敛到同一 message。
- Platform control plane 持有广播编排和恢复；workspace message domain 持有全部
  Human-visible content 与 ordinary read/unread state。

### 9.4 成本、恢复与隔离

- Canonical message transaction 与 outbox payload 的 durable row count 与 audience
  size 解耦。
- Audience reconcile 使用 bounded batch、policy version、stable cursor 与
  resumable checkpoint。
- UnreadRuntime 使用 membership、cursor、notification 与 scope generation 恢复。
- Platform target enumeration 与 delivery 使用 bounded batch、stable cursor、
  per-target lease 与 workspace-local idempotency。
- Platform principal/profile 跨 workspace 稳定；local instance、scope、message、
  attachment、membership、read cursor、notification 与 Audit 保持 workspace
  tenant isolation。