FinBayes S4 B/S 服务与商业化产品化总体设计（讨论草案）

0. 文档状态与使用方式

本文承接 2026 年 8 月 18—19 日 owner、Codex 与 Claude Code 的阶段四讨论，用于形成可供团队评审的阶段总目标、设计边界、议题与候选任务。本文会在当前讨论继续推进和收敛时同步更新。

本文不是可直接交付工程实施的详细设计，也不是第二份任务表。S4 已于 2026-08-21 进入实施；阶段、任务、负责人、依赖和状态只以 FinBayes Atlas 为准，产品定性仍以 FinBayes 战略白皮书 为准。本文只作为 Atlas 中「形成并评审 S4 总体方案」任务的过程附件；候选事项须先回写 Atlas，才可形成具体 Issue / PR。

已定：本文的体裁定位。 本文的收束目标不是一份可以直接拿去工程实施的设计文档。它要回答的是：阶段四整体要做什么、概要架构长什么样、有哪些议题、有哪些模块 / 组件 / 功能、按什么阶段拆解，以及每个议题分别有哪些强 AI Agent 与行业相似产品的参考设计和最佳实践可以借鉴。用词避免自创术语和内部黑话；表结构、索引、字段一级的技术细节留给实施期的具体设计。

决策状态使用三种标记：

• 已定：owner 已在当前讨论明确同意，可作为后续讨论的前提；
• 候选：已有方向性建议，尚未完成 owner / 团队评审；
• 待决：尚需继续讨论，不能作为实施输入。

1. 背景与当前阶段事实

FinBayes 已完成 S0—S3：主线收口、统一 Agent Runtime、Conversation / Turn / Run 生命周期与统一协议、多端 Adapter 和统一能力平面已经进入主线。S4 前的仓库瘦身与基线净化也已完成。当前需要把同一个 FinBayes Agent 从本地与单机形态推进为可持续提供服务的 B/S 产品形态，而不是建立第二个 Runtime 或另一套 Web 专用 Agent。

S4 的直接背景不是“先决定怎么收费”，而是当前系统尚未形成多人服务所需的身份、资源隔离、持久运行、服务端存储、部署运维与使用事实基础。付费模式会随市场和产品阶段变化；底层服务能力必须允许这些变化，而不能被首版套餐或计费单位锁死。

2026-08-21 owner 纠偏：第一台可部署服务器不是 S4 多用户产品。 在正式建设登录、Membership、Tenant 隔离和私有资源之前，先把当前单机 FinBayes 变成团队共同使用的一套服务器服务：无 FinBayes 登录、一个共享工作空间与历史、Web 打开即用、指定 Telegram 群通过 @FinBayes 提问，所有进入该内部服务的人都能看到共享问题、回答、等待队列和结果。多人同时提问时进入一个可见、可撤销、可恢复的服务端队列。此前把这一步写成“邀请制 Organization + 独立成员身份 + 创建者私有”的内容属于范围提前，现统一退回 S4 后续。

来源：FinBayes 战略白皮书 §7、FinBayes Atlas、FinBayes Roadmap。

2. 阶段四总目标

2.1 已定：阶段四前先交付团队共享服务器基线

这不是第二个产品、第二个仓库或临时分支，而是同一代码主线的首个服务器运行形态：

1. 只有一个团队共享工作空间，所有 Web 参与者看到同一份问题、回答、运行状态与历史；
2. Web 没有 FinBayes 登录页，进入已获准访问的团队网络或入口后直接使用；
3. 只接入指定 Telegram 群，群内成员通过 @FinBayes 提问；Telegram 问答进入同一服务器的运行与历史体系；
4. 同时到达的问题进入全局先进先出队列，首版一次只执行一个 Run；所有参与者可见队列位置，并可撤销等待中的任务；
5. 队列、问题、运行事实和回答跨进程重启保留；重启时正在执行的 Run 诚实标记为中断，等待中的任务继续排队；
6. 所有参与者共享操作权，因此首版不区分“只能撤销自己的任务”；来源信息只用于显示和排障，不用于身份授权；
7. local、团队共享服务器与后续 S4 使用同一 Runtime、Conversation / Turn / Run 合同和存储接口，以部署配置和 Adapter 表达差异。

应用内没有用户账户，不代表把服务匿名暴露给整个互联网。团队网络 / 入口准入、共享服务凭证、Telegram 群白名单、输入与队列容量、Run Budget、工具与出站网络边界仍是部署底线，但它们不是 FinBayes 多用户机制。

2.2 阶段四完整产品目标

候选总目标：把 FinBayes 建成商业模式中立、但具备商业化承载能力的 B/S 服务产品；在不复制 Agent 内核的前提下，让不同用户能够安全进入同一服务，拥有隔离且可管理的业务空间，并让 Run 在浏览器断开或服务异常时仍具有真实、可恢复解释的生命周期。

阶段出口候选如下：

1. 用户可通过稳定身份进入自己的 Tenant，并只能访问获授权的 Tenant 资源；
2. Conversation、Turn、Run、事件、结果与输入资产拥有明确的服务端权威存储和生命周期；
3. 浏览器连接与 Run 生命周期分离，断线重连、刷新、取消、失败与显式重试语义明确；
4. B/S 部署具备最小可运营性：配置、迁移、备份、恢复、健康、日志、告警与容量边界可验证；
5. 系统记录真实 usage / cost 事实，并预留权益判定层，但不预设最终套餐、价格或支付渠道；
6. local / on-prem 形态继续复用同一 Runtime 与核心契约，通过部署配置和存储 Adapter 区分，不形成代码分叉；
7. 团队用一个真实端到端交付切片验证上述能力，而不是分别交付一组无法形成用户结果的基础设施模块。

3. 阶段非目标

团队共享服务器基线明确不做：FinBayes 登录、User / Membership / Organization 管理、Tenant 隔离、个人私有 Conversation、显式共享、成员停用 / 注销、个人导出 / 删除、按成员计量、套餐和支付。它也不自动把 Web 提问转发到 Telegram 群；Web 是完整共享记录面，Telegram 群继续显示群内产生的问答，避免无条件刷屏。

S4 首版不承诺：

• 固定订阅档位、价格、充值规则、折扣、奖励或支付渠道；
• 把 credit、判断次数或“判断 × 深度”固化为产品本体；
• 复杂组织树、Workspace 层级、细粒度资源 ACL、访客与企业级 RBAC；
• 多地域、多主写入、任意执行点续跑、严格 exactly-once 或自动接管原 Run；
• 默认开启长期记忆、监控、定时任务、通知或主动复盘；
• 把审计、对账、复核、审批或永久评分做成每次 Run 的固定流程；
• 为云端与本地维护两个 Agent Runtime 或长期双写两套权威存储；
• 一次性迁移所有历史 JSONL、旧档案与已退役对象。

这些边界延续 FinBayes 战略白皮书 §8—§12 的产品原则。

4. 商业模式中立的产品化原则

4.1 已定：付费模式与定价后置

阶段四基础设施不依赖首版采用订阅、按量、席位、实例授权、免费增值或其他模式。套餐、价格、促销、额度重置奖励和支付渠道属于可变化的商业策略，不应进入 Agent Runtime、Tenant 资源模型或 Run 语义。

4.2 已定：后置定价，不后置使用事实

系统仍需在 S4 记录真实、可追溯的 usage / cost 事实，例如模型调用量、工具或外部服务成本、存储与计算占用、Run 和 Tenant 归属。否则未来无法评估成本、制定套餐、发现滥用或调整市场策略。

候选补充：使用事实必须诚实。 成本与用量事实必须来自服务商的真实回执（模型计费回执、外部服务账单事实）；估算值不得冒充事实，确需估算时必须标记为估算。这延续 FinBayes 一贯的诚实数据出处原则。当前系统只有单次 Run 的 token 硬顶，没有任何成本记账——这一模块是纯新建。

4.3 已定：后置支付，不后置权益判定

运行时需要回答“此 Tenant 当前允许使用哪些能力和资源上限”，但不需要知道用户通过何种价格、合同、活动或支付渠道获得这些权利。

层	负责什么	S4 状态
使用事实（usage / cost facts）	记录实际发生的模型、工具、存储与运行成本事实	共享服务器先按 Run / 部署记录；S4 再增加 Tenant / 主体归因
产品权益（entitlement）	表达 Organization 当前可用哪些产品能力	团队共享服务器不做；S4 建稳定判定层
资源限制（limits）	分别表达周期分配量、强制最大值、速率、并发与单 Run 预算	共享服务器先做部署级队列、输入 / 输出与 Run Budget；成员 / Tenant 限制进入 S4
套餐与定价（offer / pricing）	套餐、价格、试用、奖励、额度重置和市场策略	后置
支付与结算（payment）	支付、退款、发票、合同和结算渠道	后置

5. 身份与客户空间：User、Principal、Organization、Tenant 与 Membership

适用范围：本章属于团队共享服务器基线之后的 S4 多用户产品化，不是第一台服务器的部署前置。 共享服务器继续使用一个固定的服务范围，不创建 User、Membership 或 Organization 管理面。

5.1 已定：User 与 Principal 分层，Account 不作为授权主体

2026-08-20 经 Codex、Claude Code、Kimi 与独立研究 Agent 对当前代码、公开接口以及 OpenAI、Anthropic、AWS IAM、Clerk、Stripe、OpenTelemetry 等一手资料交叉评审，撤销此前“Account 是 S4 授权主体”的结论。User 只表示真实的人；Principal 表示经过认证、可被授权和归因的行动主体，可代表 User、未来的 Service Account 或系统主体；AuthContext 是现有已验证身份信封的解析结果，不另造第二套身份对象。Account 只允许出现在 provider account、brokerage account、billing account 等有明确限定的语境。

5.2 已定：核心对象的职责

• User：真实的人类使用者；
• Principal：请求中经过认证、可授权和归因的行动主体；
• Tenant：内部数据隔离、业务资源归属、保留、导出、删除与治理的根；
• Organization：面向用户的客户协作空间，S4 与 Tenant 一对一映射，不另建一层持久对象；
• Membership：User 与 Organization 的关系，承载其在该组织内的 Role；
• Role / Permission：Role 聚合 Permission，Permission 表达对资源执行某动作的原子授权。

tenant_id 是权威作用域与所有权边界；创建者 / 更新者标识只用于行为归因，不能替代授权判断。

5.3 已定：首版最小模型

• 首版建立 Organization 与 Tenant 的一对一关系，不引入 Workspace、Project 或 Personal Space 空壳；
• 首版可只实现最小 Membership 与 Role，但模型允许一个 User 未来加入多个 Organization；
• local Tenant 是明确的部署 profile，不是云端请求缺少 Tenant 时的隐式默认值；
• 服务端从已验证身份和 Membership 派生 Tenant，客户端提交的 Tenant 或角色声明不构成权限依据。

首版不增加 Organization → Workspace → Project 多层树，不建设逐资源 ACL，也不把个人用户直接写成每条业务记录的所有者。

已定：身份对象不是从零开始。 现有系统已经在每个请求上装配一份包含主体、租户、会话、请求等字段的身份信息，并已强制“同一认证会话只属于一个主体”。S4 的 AuthContext 是这份既有身份信息的解析与升级，不另起一套并行身份词汇。

5.4 已定：现有 scope 与 owner 名称只作为迁移遗留

当前 scope_id 是 local Tenant 内由 Principal 派生的认知资产存储分区，不是 Tenant、Organization、授权 scope、Workspace 或资源 owner。新文档和合同称其为 asset scope；首次触及其持久化合同的 S4 迁移任务再评估改为 asset_scope_id，不在讨论期做全仓抢跑。当前 owner_principal 实际表示“映射到 base workspace 的本地主体”，不是资源所有者或授权角色；触及时必须改为表达这一 local / base-workspace 关系的名称。

5.5 已定：Tenant 归属不等于 Organization 全员可见

Conversation、Report 及其派生结果默认创建者私有，只有用户显式共享后才对其他 Organization 成员可见。TG Channel、Organization 群组等明确共享 Surface 本身就是用户选择的共享场景，可以在创建时声明共享受众；Web 私聊、DM 和个人入口默认私有。派生报告继承来源 Conversation 的可见性，不得自行扩大受众。创建者字段只做归因，实际访问仍由 Membership、Permission 与共享关系裁决。

6. 持久化资源与归属分类

本章同时服务共享服务器与 S4，但作用域不同：共享服务器的业务资源统一归固定共享范围；S4 再把相同资源合同置于 Tenant 和对象可见性之下，不为两种形态建立两套对象。

“所有持久化资源都归 Tenant”并不准确。正确规则是：所有客户空间业务状态、用户内容与 Agent 运行产物必须带 Tenant 作用域；平台身份、平台控制面和运营事实按其自身生命周期管理，并在需要时记录 Tenant 归因。

6.1 Tenant 所有的业务资源

• Conversation、Turn、Run、RunEvent、RunResult、原始完成回答与结果快照；
• Run 的 capability binding、取消、重试、中断和父子 Run 关系；
• 结果解读：回答完成后的可选结构化解读，拥有独立的开始 / 局部产出 / 完成 / 失败生命周期和用户显式重跑入口；它是 Turn 的异步附属产物，不是 Run 的必经步骤；
• 报告库：用户显式保存的报告、标签与重开入口；
• 用户输入、上传资产、解析结果、派生图表、表格和导出包。注意：上传资产在当前系统中完全不存在（文件读写目前是 Agent 在回合内使用的工具，没有上传入口），它是新建能力而不是迁移，工作量单列；
• Tenant 级能力配置：启用能力、连接的数据源、Provider 选择、Skill / MCP / Plugin 状态、默认 Run Profile、保留期与资源限制；
• 用户明确启用后的 Memory、关注项、监控、定时任务、通知和后台 Run；
• Tenant 数据导出、删除、保留和关闭所需的业务状态。

Secret 本体进入专用 Secret Manager；Tenant 业务记录只保存引用和必要元数据。

6.2 不属于 Tenant 的资源

• User / Principal、外部身份映射、登录安全状态和平台级身份安全记录；
• Membership 本身是 User 与 Organization 的关系；
• 平台模型 / Provider 注册表、公开 Skill / Plugin 清单、迁移、全局策略、服务配置和文档；
• 公共或共享金融数据缓存；对缓存的访问使用仍需 Tenant 归因；
• 平台健康、部署和运行日志；其中可以包含受控的 Tenant 归因字段。

6.3 平台所有、Tenant 归因的事实

Usage / cost 记录是平台运营与未来商业决策的事实，不应简单随 Tenant 业务内容一起删除。它们必须带 Tenant 归因，并通过保留、隐私与合规策略控制可见字段和保存周期。

7. Conversation、Turn 与持久 Run

7.1 已定：最小持久语义

• Run identity、状态、输入引用、事件、结果和关键 capability binding 持久化；
• 浏览器断开、刷新或关闭不终止 Run；重新连接后可查询状态并续读可用事件或最终结果；
• 服务进程崩溃不能把未完成 Run 标成成功；若无法继续，状态进入 interrupted；
• 用户显式重试创建新 Run，并保留原 Run 及关联关系；
• cancel 是显式控制动作，必须区分“请求取消”“已取消”和“已完成后取消无效”。

7.2 首版明确不承诺

• 进程重启后自动接管并继续原 Run；
• 从任意 token 或工具调用中点恢复；
• exactly-once 工具副作用；
• 多区域、多主写入和任意实例无损接管。

7.3 已定：沿用现有状态词，只补“中断”

对现有 Run 合同的核对结论：现有生命周期状态里有两种用户可见的诚实状态——“正在等待用户补充输入”和“已降级但仍诚实产出”，另有“产物已就绪”这样的中间状态。此前候选的“排队 → 运行 → 成功 / 失败 / 取消 / 中断”通用状态模型装不下它们，压平成“运行中”会丢掉诚实语义。

因此 owner 已定：以现有状态集为准，interrupted（中断）是唯一真正缺失的新状态；“已取消”由现有中断路径的终局映射；不引入另一套通用云端状态词表。interrupted 的恢复动作在首版是“查看已有事实并显式创建 retry Run”，不是伪装成原 Run 自动续跑。

8. 存储与部署 profile

共享服务器直接使用单实例 PostgreSQL 保存队列、幂等窗口、Conversation / Turn / Run / RunEvent / Result 及共享工作面所需的权威索引与快照；这是对 owner 已批准“首版完整 RunEvent 进入 PostgreSQL”的延续，也避免先扩建文件多写一致性、进入 S4 再迁一次。对象存储仍只随 InputAsset 或大件产物的真实需要引入，不阻塞共享服务器。

8.1 候选方向

• PostgreSQL 在团队共享服务器先承载队列、幂等、Conversation、Turn、Run、完整运行事件、共享工作面与必要 Usage / Cost 事实；S4 再在同一存储接缝增加身份、成员关系和 Tenant 作用域；
• 对象存储承载上传文件、大型结果、导出物和不适合进入关系库的二进制材料；
• local / on-prem profile 首版继续使用文件系统和现有存储 Adapter，但遵守相同对象标识、Tenant 作用域和生命周期合同；
• B/S 云端不维持两套长期并行的权威存储，不默认迁移所有历史文件；
• 通过存储 Adapter 与部署配置复用同一 Runtime，不建立通用“平台中台”。

8.2 已定：首版完整运行事件进入 PostgreSQL

首版不采用“关系库只存索引 + 对象存储保存事件日志”的冷热双存储。完整运行事件进入 PostgreSQL，事件在每个 Run 内按顺序编号，以支撑断连续读、Tenant 隔离、终局判断与故障排查；具体表结构留给实施设计。只有真实容量、成本或保留期证据出现后，才评估分区、归档或冷热分层。

8.3 已定：local profile 首版不引入 SQLite

local / on-prem 首版保留现有文件存储 Adapter，不为了与云端 PostgreSQL 表面一致而新增 SQLite。新 local 数据必须显式绑定固定 local Tenant；大型资产由本地文件系统实现与云端对象存储相同的资产接口；云端与 local 通过共享领域对象、存储合同和跨 Adapter 合同测试保持语义一致。

首版不默认迁移全部历史 JSONL，也不把旧文件与新 PostgreSQL 做长期双写。只有本地复杂查询、事务或并发需求出现真实证据后，才重新评估 SQLite。

8.4 已定：四个存储边界问题的结论

1. 过程记录与结果同寿命。 分析过程中滚动产生的事件记录，在分析结束后仍完整保留；团队几天后重开旧对话，看到的是完整过程而不只是最后的结论。共享服务器按部署保留策略处理且不提供个人删除；S4 再随 Tenant 数据生命周期处理删除。断连续读的游标沿用现有约定，不另造一套。
2. 先存大文件，后记“完成”。 小信息（标题、状态、时间）在数据库，大文件（完整报告、图表、上传文件）在对象存储。数据库记下“这份结果完成了”之前，大文件必须已经存好——数据库说“有”，文件就一定在。反过来做会出现用户点开一份空报告，这是验收草案明确不允许的“显示成功但内容丢失”。存了一半的废文件由后台定期清扫，不影响任何人。
3. 一台起步，但不把“只有一台”写死。 首版单实例部署，不在第一天就外置队列与实时状态。纪律只有一条：“现在谁在跑、跑到哪了”这类运行状态记在数据库里，不能只记在这台服务器自己的内存里。守住这条，以后加机器是部署变化，不是重写（GitLab / Sentry 先例）。
4. 删除与导出是能看进度的任务。 用户按下删除，第一步立即生效——访问封住，数据谁也看不到；然后系统在后台逐个存储清理，全部清完才显示“删除完成”；中途服务重启，任务接着干。导出同理，打包完成才给下载。usage / cost 事实按 §6.3 单独保留，不随业务数据一起删。

9. 身份接入与请求上下文

适用范围：本章属于 S4 后续。 团队共享服务器没有 FinBayes 登录和成员身份解析；网络 / 入口准入以及 Telegram 群白名单只决定谁能进入这套内部服务，不产生 User、Membership、Tenant 或私有资源。

候选认证链为：

外部凭证 → 身份提供方 Adapter → User / Principal → Membership → Organization ↔ Tenant → AuthContext

请求上下文至少应包含稳定 Principal、当前 Tenant、Membership 关系、请求身份强度和必要的服务主体信息。下游不重新解释客户端 token，也不从请求参数猜 Tenant。

首版候选边界：

• 采用成熟身份提供方的 Adapter，不自行建设密码、MFA、找回和风控系统；
• 引入外部身份服务时，只替换“认证”这一层；现有的会话管理与断连续读地基已经过单机形态验证，不要连带替换；
• 首版不支持匿名、Guest 和外部 Service Account；
• 后台任务若需要机器主体，必须与发起 Tenant 和创建者关系可追溯；
• 身份供应商可替换，内部 User / Principal 与 Tenant 标识不能随供应商变化。

9.1 已定：S4 多用户首版登录方式只做两种

• 邮箱验证码（不设密码，每次邮件收码或点链接登录）和 Google 账号一键登录；
• 两种都不用管密码，覆盖面足够；手机短信登录有接入成本，等有真实用户证据后再加；
• 具体签哪家登录服务商属于实施期选型，拿真实报价和试用结果再定。草案只记三条选型标准：可替换、不锁死我们的用户数据、支持我们将来自部署。

9.2 已定：本地版不设登录

本地版（用户自己电脑上跑的形态）保持现状：打开就用，不加登录。这是它的优点，加登录对单机用户是纯骚扰。团队共享服务器同样不设 FinBayes 登录，只在网络 / 部署入口限制访问；应用内登录只属于后续 S4 多用户服务形态。

10. Web / API 服务合同

服务合同分两步生长。团队共享服务器的连续路径是：打开 Web 或在指定 Telegram 群 @FinBayes → 提交问题 → 查看等待位置 → 运行 → 获得结果 → 刷新或重启后继续查看共享历史 → 继续追问、撤销等待任务或中断运行。S4 多用户路径才增加登录、Tenant、创建者私有和显式共享。

三个标识不得混用：request_id 是传输、幂等和关联标识；turn_id 是持久的一次产品交互；run_id 是该 Turn 的一次具体执行尝试，retry 创建新 Run。当前 /turns/{request_id} 属于已识别的接口命名漂移，在 §10.1 的 S4 API 一次性切换中处理，不在本轮设计兼容壳。现有公开 session_id 明确定义为 Auth Session 标识，保留既有寿命、幂等和帧史合同；是否改成 auth_session_id 随同一次 API 命名空间切换处理。

已定要求：

• API 资源围绕 Conversation、Turn、Run、事件、结果、结果解读、报告库和上传资产，而不是当前页面组件；
• 创建 Run、取消、重试和附件上传具备明确幂等边界；
• 事件流只是运行事件的传输方式，不是唯一事实源；
• 客户端不能提交并信任 tenant_id、角色或资源所有者；
• 错误区分认证失败、无 Membership、资源不存在、跨 Tenant、限额、运行失败与服务中断；
• Web 继续是统一 Runtime 的薄 Surface，不复制业务状态机或 Agent Loop；CLI、TUI 和聊天渠道不因 API 重划而被强制绕行 HTTP，它们继续通过各自 Adapter 复用同一应用 / Runtime 合同。

10.1 已定：目标设计前置，工程切换进入 S4

现有接口按页面形状组织，上述资源化与之不兼容。阶段四开始前先批准目标资源边界、消费方关系、迁移范围和验收口径，但不抢跑改路径或客户端；接口、Web、生成类型与 Handbook 的实际替换属于 S4 第一实施切片。 现行 OpenAPI / Handbook 在切换前继续只描述当前可运行事实，不能提前写成目标形态。

切换遵守一个原则：目标合同在隔离开发与验证完成后，与所有保留的 Web 消费方同批启用，旧 /workbench/* 同批退役，不在运行产品中长期并存新旧命名空间，也不建立兼容壳。CLI、TUI 与聊天渠道不是当前 HTTP 消费方，迁移的是它们共享的应用语义，而不是强迫它们多走一层网络。

当前审计确认并收进 S4 的接口层缺口包括：

1. 对话列表有列表无单条读取，是一条死路；
2. 缺少 AuthSession 撤销（登出）与剩余寿命查询；
3. 开发 / 本地模型配置入口游离在正式合同之外，且实际装配与“仅开发使用”的描述不一致；它应归 local 管理 / 配置面，不进入 hosted 用户资源 API；
4. /turns/{request_id} 把 Request、Turn 与 Run 混为一个路径身份；
5. Handbook、Web 驱动、合同测试、OpenAPI 与服务实现曾存在快照漂移。2026-08-20 已恢复结果解读单次读取、Report Library、Capabilities 的服务路由与装配、Web 网络调用、OpenAPI、Handbook、生成类型和合同测试；2026-08-21 又完成 SourceAnswer、失败语义、解读快照、报告库入口、交互联动与三语文案的 Web 呈现收敛。当前 Web 类型检查及 84 个测试文件 / 817 项测试全部通过，当前可运行基线已一致。

**已定处置（当前基线恢复已完成）：**结果解读单次读取、Report Library 与 Capabilities 继续作为已有本地 Web 产品能力；模型配置明确归 local 管理面。Conversation 单条读取、AuthSession 撤销与寿命查询属于 S4 目标合同，不在阶段四前另补一套马上退役的临时接口。

截至 2026-08-21，现行 OpenAPI 为 26 条路径、28 个操作；新增的共享活动、结果读取和就绪接口仍属于当前 /workbench/* 可运行合同，不改变下述 S4 目标资源边界。

10.2 已定：目标资源图与非资源边界

目标 API 按用户与产品中的稳定对象组织，而不是按当前页面面板组织：

• 访问与协作：AuthSession、Organization、Membership 与显式共享关系。Tenant 由服务端可信身份链解析，不接受客户端自行声明；
• 对话与执行：Conversation 包含 Turn；每次实际执行形成 Run；RunEvent 表达可续读进度；Result 是终局后可重新读取的权威结果；
• 派生产物：Interpretation 是 Turn 的可选异步附属结果，Report 是用户显式保存的持久资源；二者继承来源可见性，不得自行扩大受众；
• 输入资产：InputAsset 是后续独立新能力，不阻塞首个对话垂直切片，也不为凑目标资源图提前建立空接口；
• 真实领域资源：Monitor、Notification、Preference、市场数据读面等保留其已有产品含义；它们不是首个多用户主流程，但作为已有 Web 功能须在旧 API 退出前迁移，不为凑统一词表而改名；
• 请求关联：request_id 只用于传输关联与幂等，不是用户长期管理的“回合资源”；
• 部署配置：本地模型 / Provider 配置属于 local 管理面，不属于 hosted 用户业务资源 API。

事件流只负责传递 RunEvent 与游标，普通读取接口负责返回当前权威状态与结果。客户端断流后必须能用 Run 标识重新读取状态、从游标继续接收保留事件，并在 Run 已终结时直接读取 Result；不能把一条仍然活着的 SSE 连接当作任务存在的证明。

10.3 已定：首个实施切片与切换验收

当前最近实施切片不再从 AuthSession 和登录开始，而是贯通：内部入口打开即用 → Web / Telegram 提交问题 → 全局等待队列 → 单 Run 执行 → RunEvent / Result → 队列撤销与运行中断 → 重启后恢复共享队列和历史。

这一切片复用当前固定 local Principal / Tenant 作为部署内部事实，不把来源显示名、浏览器连接或 Telegram sender 误建成 User。所有进入该内部服务的人共享可见性和操作权；Web 汇总展示 Web 与 Telegram 的问题和结果，Telegram 不自动接收 Web 问答广播。

完成共享服务器基线后，S4 工程再从真实身份与 AuthSession 生命周期进入，首个多用户垂直切片仍然是：登录 → 创建者私有 Conversation → Turn / Run → RunEvent → Result → 断连后恢复 → 显式共享。 前一个切片交付的队列、持久运行、事件和结果合同继续复用，不重写第二套。

InputAsset 可以排在后续独立小批次。Monitor、Notification、Preference、市场读面和无 Secret 能力清单已经有真实 Web 消费者，属于保留功能；它们不必成为首个多用户切片的主流程，但必须在旧 API 退出前迁移到目标合同或稳定读模型，不能留下静默死面。当前 Case、Projection、Task 是页面形状的读面，它们保留的用户能力应映射到 Conversation / Run / Result / Interpretation / Monitor 等稳定资源，不因现有路径名自动升级为新的产品本体。

团队共享服务器先在现有 /workbench/* 合同上做最小扩展，不抢跑 S4 资源命名空间重划。其验收必须证明共享队列、跨 Surface 记录、持久结果、撤销 / 中断和真实服务器运行成立。S4 实施时再让 OpenAPI、Handbook、服务实现、生成类型和 Web 消费方同批切换，并验证登录、私有资源、断连恢复、结果重读和显式共享。

10.4 已定：服务 API 的安全底线

团队共享服务器先执行部署级安全：只允许团队网络 / 入口访问，使用共享服务凭证，Telegram 只接指定群，所有请求受全局队列容量、输入 / 输出大小和 Run Budget 约束。以下对象级授权、Tenant 与 AuthContext 要求在 S4 多用户化时启用；不可信输入 / 输出处理、Secret 保护、工具最小权限和资源上限自共享服务器起就是部署底线，不反向阻塞当前共享基线，也不能整体后置。

• 长寿命 AuthSession 凭证不放进 URL；浏览器与非浏览器客户端分别采用适合自身的安全承载方式，SSE 鉴权方式在实施设计中确定；
• 每次资源读取、事件续读、取消、重试和共享都做对象级授权；Tenant、角色、创建者和共享受众由服务端解析或校验；
• 用户输入、网页、文件、聊天频道材料和检索内容都按不可信内容处理，不能改变身份、权限、工具策略或系统指令；
• 模型输出同样是不可信输入，未经结构校验和上下文转义不得直接成为 HTML、SQL、Shell、URL 抓取或高影响动作；
• 工具能力从 AuthContext 与当前 Run 的许可中最小化授予，高影响动作需要显式确认，未知动作默认拒绝；
• 密钥不进入 prompt、RunEvent、Result 或客户端诊断；日志与审计记录做脱敏；
• 对输入大小、并发、速率、Run Budget、输出量和资产大小设置可解释限制，失败时诚实降级而不是继续无界消耗。

10.5 已批准：Web / API 一次性切换包

本节只属于 S4 多用户 API 重划。团队共享服务器不会为了短期部署先切一次 API、进入 S4 再切第二次；它只补共享队列与共享读取所需的现有合同能力。

这个“切换包”不是另一份工程设计文档，而是正式进入 S4 前需由团队共同确认的五项边界：

评审项	需要确认什么	当前结论
目标资源	用户真正看到和管理的对象	以 AuthSession、Organization / Membership、Conversation、Turn、Run、RunEvent、Result、Interpretation、Report 及既有 Monitor / Notification / Preference 为主；InputAsset 后续独立建设
现有功能去向	哪些保留、哪些后置、哪些只属于本地管理面	结果解读、报告库、监测、通知、偏好、市场读面和无 Secret 能力清单全部保留并在旧路径退出前迁移；本地模型 / Provider 配置不进 hosted 用户 API；Case / Projection / Task 页面读面映射到稳定资源或读模型
各端调用关系	Web、CLI、TUI 和聊天渠道如何复用同一能力	Web 迁移新 HTTP 合同；CLI、TUI 与渠道继续通过 Adapter 复用同一应用 / Runtime 语义，不强制绕行 HTTP
原子切换	什么必须同批替换，旧路径何时退役	服务实现、OpenAPI、Handbook、生成类型和所有保留的 Web 调用方同批切换；旧 /workbench/* 在无保留调用者后删除，不留长期兼容壳
端到端验收	什么结果才表示第一切片真正成立	真实浏览器贯通登录、创建者私有对话、运行进度、持久结果、断连恢复和显式共享；跨 Tenant 读取 / 写入 / 事件续读 / 取消 / 重试均有反向验收，凭证不进 URL，Secret 不进 prompt / 事件 / 结果

上述五项已经通过 S4 本地开工准入。具体路径、字段、数据表、SSE 承载方式等属于 S4 实施设计，不在本讨论草案中提前冻结；实现必须在隔离分支完成整包验证后同批切换，不得据此提前改写当前 OpenAPI / Handbook。

11. 用量、成本与权益

本章采用以下规范概念：Usage 是带来源、单位、时间和归因的消耗事实；Provider Usage 是服务商回执事实；Metered Usage 只在 Meter 接受并聚合符合规则的计量事件后成立。Cost 是 FinBayes 内部支出并区分 provider-reported 与 estimated；Price 是客户价格；Permission 是成员动作授权；Entitlement 是客户可用产品能力；Quota、Limit、Rate Limit 与 Run Budget 分别表达周期分配量、强制最大值、使用速度和单 Run 的迭代 + token 双维执行约束。Subscription 是持续商业关系。S4 不建立通用 credit；Billing Credit 仅为未来真实可抵扣账本资产保留。

团队共享服务器只需要按 Run 和整个部署记录必要的 Provider Usage / Cost，设置全局队列容量、并发数、输入 / 输出和 Run Budget；没有成员、Tenant、Entitlement、个人用量或套餐。以下组织级归因与可见性设计属于 S4 后续。

S4 不建立 Billing Customer 对象，也不提前设计一个付款主体覆盖多个 Organization。该需求更可能随集团采购、独立部门或 private / on-prem 合同出现，但也可能出现在 hosted enterprise，因此当前只保留一条演进纪律：Tenant 不永久等同于付款主体；真实合同出现时再增加独立 Billing Customer 与 Organization 的关系。

11.1 当前事实：有运行预算和零散遥测，还没有产品用量账

当前 Provider 接口可以携带 token usage，主 Agent Loop 会汇总 Provider 返回的部分 token 数；Provider 不返回时，Run Budget 以字符量估算兜底并标记 estimated。这个机制的目标是防止单次运行无界消耗，不是客户用量或财务账：Codex Provider 当前完全没有 token usage 回执；estimated 只是 Run 级粘性标记且正常完成时没有完整披露；retry / fallback 的失败尝试、强制收束、结果解读和子运行等也尚未形成一份完整可对账事实。更重要的是，失败的 Provider 尝试目前既不进入 Usage，也不扣减实时 Run Budget，因此这部分消耗需要在 S4 诚实补齐。

现有数据取用遥测记录金融数据工具调用了哪些数据类型与数据源，用于判断能力内化优先级；它是系统级、无主体归因、best-effort 的能力遥测，不是用户 Usage、Cost 或未来计量事件。现有 Permission 接缝主要回答某主体能否执行动作，尚无按 Organization 授予产品能力的 Entitlement。共享服务器已补部署级输入、队列容量、全局单执行槽和只能收紧的 Run Budget 边界；这些是安全资源限制，不是成员 Usage、Tenant 配额或商业权益。成员 / Tenant 级归因和限制仍在 S4 多用户化时新建。

因此，S4 不是把现有字段改名后直接用于计费，而是保留这些运行安全能力，同时补一条来源诚实、可归属、可对账的产品事实链。

11.2 候选：S4 多用户里程碑的五层最小接缝

层次	首版做什么	明确不做什么
Usage	记录实际发生的 Provider、模型、工具或外部服务消耗，并归因到 Tenant、发起主体、Run 与发生时间（适用时）；Provider 未回传的值记为 unknown，运行安全估算另行标明 estimated	不把未知写成 0，不把现有数据取用遥测、RunEvent 或所有工具调用预先当作未来计量事件
Cost	保存或汇总 Provider 可核验的成本；只有根据带版本价格资料推算的结果才标 estimated，并与 Provider 组织级账单定期对账	不把内部 Cost 当客户 Price，不在 Runtime 内解析套餐、折扣或促销
Entitlement	判断某个 Organization 当前可用哪些产品能力；S4 首批 Organization 使用简单、可配置的能力集合	不把成员 Permission、剩余额度、套餐名称或 UI 开关当成 Entitlement
Limits	以 Usage Limit、Rate Limit、Concurrency Limit 和 Run Budget 等通行概念，在成员、Tenant 与部署层设置并发、速率、输入 / 输出大小和高影响工具边界	不先造月度 Quota、复杂预留账本或商业超额机制；没有真实周期分配量时不用 Quota 一词
Visibility	成员查看自己可用能力、当前限制和自身用量；Organization 管理员查看组织的 Usage、能力和限制汇总；平台运营查看内部 Cost 与容量但默认看不到私有内容	不向客户暴露 FinBayes 内部采购成本，不把 Provider 凭证、prompt、Conversation / Result 正文或可下载资产地址写入用量与成本记录

Provider 调用尝试是最小事实单位，Run 是聚合视图。每条使用事实至少带清晰来源、单位、时间和 Tenant / Run 归因，并进入与 RunEvent 同等级的服务端权威存储，不依赖 hosted 默认关闭的 Trace 或容器临时文件。Provider retry 或 fallback 产生真实消耗时，每次尝试都应如实计入；产品请求的幂等不等于上游调用“精确一次”。同一次尝试要么使用 Provider 回执，要么使用明确标记的估算，不得两者相加；暂时拿不到上游事实时呈现 unknown。后续通过 Provider 组织级 Usage / Cost 报告对账，发现差异时追加纠正事实而不改写原始记录。

11.3 候选：权益与资源限制如何进入一次 Run

• 团队共享服务器的 Run 开始前只检查部署级准入、全局队列容量和 Run Budget，不解析 Membership、Entitlement 或个人余额；

以下身份、组织权益与数据生命周期规则只在 S4 多用户服务中启用：

• Run 开始前依次完成身份、Permission、Entitlement 和 Limits 判断；拒绝时给出可理解的原因及是否可重试，不使用“credit 不足”等未建立的概念；
• 复用现有“首次模型调用前冻结运行能力快照”的接缝，把 Organization / 成员生效的能力与限制解析进去，不另建平行快照机制。普通配置变化只影响新 Run；Organization 停用、成员移除、能力紧急关闭等安全撤销通过独立的中止 / 禁用通路立即阻止新的高影响动作或中止活跃 Run，且仍记录中止前已经发生的 Usage；
• Runtime 只执行已解析的能力与资源边界，不知道套餐、价格、促销和支付；执行结束后记录真实 Usage，再生成或对账 Cost；
• 团队共享服务器以硬性的部署级安全上限和运营告警控制成本，不用可能延迟的金额估算代替实时 Run Budget、队列容量和单执行槽保护；
• Usage / Cost 是平台运营事实并带 Tenant 归因，记录中不保存私有内容；Conversation 删除不应伪造这些事实从未发生。保存周期、访问范围、最小聚合和去标识化策略必须在 hosted 内测开放前确定，并明确告知成员 Organization 管理员可见哪些汇总。

这一最小接缝不要求先确定如何收费，也不妨碍未来把 Subscription、Price 或人工合同映射为 Entitlement。首版成员只需要看到自己的使用与限制，Organization 管理员看到组织汇总；内部金额成本只属于平台运营视图，不把内部采购成本塑造成客户价格。

12. 部署、运维与数据权利

12.1 已定：网络暴露是显式准入，不是放松既有约束

本地形态“只在本机可达”是一条已生效并有负向测试保护的安全约束（配置里看似可改的监听地址是被显式忽略的）。S4 的服务形态必须通过显式的 hosted 部署配置获得网络暴露准入；local profile 继续钉死本机回环并保留负向测试。这是安全边界决策，不能留给实施时顺手放开。现有 deployment_mode 的含义只是诊断详略，S4 实施时可在明确扩宽它的合同后复用，也可以引入职责更单一的 deployment profile；两种做法都必须保持一套代码且 local 安全默认不变。

owner 于 2026-08-21 明确要求建立团队共享服务器，因此过去“非回环绑定一律禁止”的决定只对 local 形态继续有效；服务器部署配置在不放松 local 回环负向测试的前提下获得显式网络准入。这个准入只允许固定共享服务进入团队网络，不代表 Organization / Membership、多用户身份或匿名公网访问已经启用。

12.2 已定：最小运维面

• 数据库迁移可回滚或具备明确前滚恢复路径；
• PostgreSQL 与对象存储的备份、恢复演练和恢复目标明确；
• 健康检查区分进程存活、依赖可用和是否可接受新 Run；
• 日志、指标与告警在共享服务器先按 Run 和部署归因，S4 再增加 Tenant / 主体归因；二者都不得泄露 Secret；
• 配置、Secret 引用和 Provider 凭证不进入代码、日志或客户端；
• 部署升级时明确在跑 Run 的排空、中断和回退策略；
• S4 多用户化后再加入 Tenant 导出、删除和关闭；共享服务器基线没有个人数据权利或成员生命周期管理面。

部署方向已定：先交付团队共享服务器，S4 再在同一主线上增加多用户 hosted 服务；高安全或数据主权场景保留 private / on-prem 部署。各形态以 configuration、Adapter 和 deployment profile 表达差异，不分叉 Runtime。团队共享服务器从单实例起步，何时横向扩展由真实容量与可靠性需要触发。

12.3 当前事实：本地实现与离线验收完成，Railway 部署验收中

截至 2026-08-21，团队共享服务器已在同一代码主线上形成显式 shared_server 部署模式：Web 与指定 Telegram 群共用 PostgreSQL 权威状态、全局 FIFO 单执行槽、跨重启队列与历史、共享活动面和 Telegram 文本可靠投递；Docker、Railway 配置、存活 / 就绪、单实例租约、故障退出、SIGTERM 排空、资源上限、工作区与出站网络边界，以及冷备份 / 恢复工具均已落地。真实 PostgreSQL 17 的离线往返与负面合同已通过 34/34，首次部署可重复执行空库初始化或当前 schema 验证。

这不等于基线已经完成生产验收。团队成员正在 Railway 上部署；真实持久卷与 Secret 注入、平台信号、团队边缘入口、两个独立浏览器、指定 Telegram 群、断线 / 重启 / 恢复和未获准入口负测仍需在同一套服务上通过并回写证据。服务仍不得匿名直暴公网；透明共享 token 只是团队边缘内的会话握手，不替代网络准入，也不引入 User、Membership 或 Tenant 多用户模型。

12.4 已定：第一服务器版本是无登录的团队共享服务

它位于 S4 多用户产品化之前，但不是临时代码分支：

• 一个部署、一个固定共享工作空间、一个 Web 共享记录面；所有进入内部服务的人都能看到 Web 与 Telegram 产生的问题、等待状态、回答和结果；
• Web 没有 FinBayes 登录，当前共享 token 继续作为服务凭证并由页面透明使用；团队网络 / 入口层决定谁能到达服务，默认仍禁止匿名公网访问；
• Telegram 只接受配置中指定的群组，并继续要求 @FinBayes 或回复 Bot 才触发；群成员不再按 sender 拆分认知资产范围，当前部署内使用同一共享工作空间；
• Telegram 的准入主语从逐个 sender 改为指定 chat：群成员关系即准入，移出群即撤销；保留可配置的紧急 sender denylist 只用于快速止损，不把它扩建成用户或成员系统；
• Web 与 Telegram 保持各自 Adapter，不强迫聊天渠道绕 HTTP，也不建立第二 Runtime；二者把 Run 登记到同一服务端队列和共享历史；
• 首版全局先进先出、单执行槽。每个问题提交后先成为可见的等待任务；任何进入内部服务的人都可撤销等待任务，也可中断运行中任务；
• 队列、Conversation、Turn、Run、RunEvent、Result 与必要来源信息进入可恢复的服务端存储。服务重启后等待任务继续排队，执行中的 Run 诚实进入 interrupted，已完成回答仍可查看；
• 起步仍是单实例；多实例、外部队列、Redis、对象上传、全量可观测平台、多地域、登录和多 Tenant 全部后置；
• Railway 或其他托管平台只是可替换部署选项，不进入 FinBayes 产品对象模型。

Web 是完整共享记录面，Telegram 群自然看到群内问答；首版不把 Web 问答自动广播到 Telegram，以免共享队列变成群消息刷屏。来源 Surface、Telegram 显示名或浏览器生成的关联信息只用于呈现和排障，不是 User 或资源所有者。

12.5 已定：单实例升级与排空合同

阶段	对用户的真实行为
开始排空	单独关闭“新问题入队”，诚实告知暂时不接新任务；共享队列、历史、结果回取和事件恢复继续可读，不立即把整个单实例从入口摘除
运行中任务	收到 SIGTERM / SIGINT 后立即请求中断本进程捕获的 running Run，并在同一事务中唯一收口为 interrupted(shared_server_shutdown)；不等待它自然完成，也不冒充成功、失败或取消
等待任务	queued Run 保留在 PostgreSQL 中但不再启动；首版不把 Monitor / Cron / Heartbeat 迁入共享服务器
重启后	共享服务会话可重新建立，队列 / 历史 / 幂等窗口持续有效；相同 request_id 重试不能悄然重复执行

interrupted 作为新的持久 Run 终局语义，必须在共享服务器批次中同步进入现行服务合同、Handbook、生成类型与 Web，不只留在存储或运维日志里；这属于现有 /workbench/* 的最小合同扩展，不提前触发 §10 的 S4 API 命名空间重划。

12.6 已定：存活、就绪与 Run 准入是三件事

• 存活只回答进程和公开 API 是否可达，不泄露依赖、账号或运维详情；
• 就绪表示实例能否安全接受流量，受必需持久存储、迁移状态和最终退出阶段影响；细节只对运维身份可见；
• Run 准入独立表示当前是否可以开新运行。单实例排空时它先关闭，而已授权的读取与恢复仍可服务；只有真正无法安全服务时才把整个实例标为不就绪。

12.7 已定：恢复的是一致的权威数据，不是单个数据库

• 恢复集覆盖 hosted 形态实际启用的每个权威存储；已保留能力不得留在未备份的容器文件中；
• 数据库中的 Result / Report 记录与对象存储中的大件内容必须恢复到可相互引用的一致点；若首批未启用大件资产，对象存储不作为首切片前置；
• hosted Secret 来自托管平台或专用 Secret Store 的注入，不进入数据库备份，不依赖 macOS Keychain，更换 Secret 不需要改代码；
• 团队内测初始恢复目标为 RPO 不超过 1 小时、RTO 不超过 4 小时；真实恢复若仍有数据缺口，必须在共享记录面如实呈现，不用空记录或伪成功遮盖；
• 正式开放团队内测前必须完成一次备份恢复演练；存储边界或迁移方案发生重大变化后重新演练。

12.8 已定：共享历史与运营日志分开

团队共享服务器中的问题、回答、Run 状态和结果本来就是面向团队共同查看的产品历史，应进入权威存储；这不等于把同样正文复制进容器日志和告警。运营日志只记录必要的结构化、脱敏事实，覆盖队列长度、等待时间、失败 / 中断 Run、Provider 故障、迁移 / 备份 / 恢复失败和资源饱和，不记录凭证、Secret 或可直接下载的资产地址。

当前本地 Trace 会记录模型可见消息和工具参数。共享服务器默认关闭无界内容 Trace；需要调试具体 Case 时，以明确 Run 为范围临时开启、限制保存时间并让团队知情。S4 多用户化后再增加私有内容隔离、管理员访问和合规保留规则。

12.9 已定：资源安全是内测准入，不是商业化附件

团队共享服务器在网络可达之前，必须具有部署级队列容量、单执行槽、入站速率、输入 / 输出大小与 Run Budget 边界；文件工具限制在工作区，出站请求不得访问本机 / 内网 / 云管理地址，Exec 保持关闭。这些是防止异常请求、自动化循环或间接提示注入耗尽整个团队服务的运行底线，不等待登录、套餐或计价。成员 / Tenant 级限制进入 S4。共享认知资产的写入保留来源 Surface 与必要关联信息，供团队排障和回滚；这些信息用于运行追溯，不被解释成 User、属主或授权依据。

12.10 S4 后续候选：多用户安全裁决不交给模型

本节从共享服务器演进到登录、多 Tenant 和私有资源时启用，不是共享服务器部署前置。共享基线已经通过团队入口、固定共享范围和部署级工具边界控制访问。

当前主线已有统一 Permission 判断入口、身份信封、Secret 脱敏和工具副作用分类，但当前 Web 只有一个共享 Principal 和固定 local Tenant，对象属主检查实际无法区分不同成员；已验证主体基本全部放行，缺少身份信封时整个工具准入判断根本不会发生。Report Library 仍是工作区共享文件，联网抓取与文件工具也没有多用户 hosted 所需的网络和工作区隔离。这些事实不阻碍按 §12.4 建设固定共享空间，但不足以直接开放独立身份、私有资源的 S4 服务。

hosted profile 应把以下边界作为服务端规则，而不是 prompt 约定：

• 每个入口都先解析可信 AuthContext、Membership、Tenant 与资源可见性；缺少身份、未知能力、越权对象默认拒绝。local profile 可以保留当前可信本地行为，但不得把这条便道带到 hosted；
• Web、Telegram、未来 Channel、定时任务和工具调用使用同一套身份、授权与资源可见性规则。hosted 下的可见性只由服务端从已验证身份派生，调用方传入的 scope 或归属参数不再作为受信输入；子运行、持续监测和定时任务继承发起成员的身份与可见性，不得自铸系统主体。平台系统主体只用于不处理成员内容的运维动作；
• hosted 的非 Web Surface 必须先把外部账号绑定到有效 Membership 才能发起 Run；未绑定账号只能看到已经明确发送到共享 Surface 的内容，不能启动工作；
• 用户输入、网页、文件、检索结果和 Channel 消息都只是待处理内容，不能修改身份、权限、系统规则或工具准入；模型输出在进入 UI、URL、查询、命令或高影响动作前必须校验和安全处理；
• 每次 Run 只获得完成任务所需的最小工具、文件目录与网络范围；hosted 强制把文件工具限定在工作区，联网能力不得访问本机、内网或云平台管理地址，重定向也不能绕过。Shell / Exec 保持默认关闭；首个里程碑不开放任何需要人工确认的高影响动作，未来引入时无人确认即拒绝，不让持久 Run 无限挂起；
• Secret 不进入 prompt、RunEvent、Result、客户端诊断或普通日志。系统提示词不被当作安全边界，即使被推断或泄漏，身份与权限规则仍必须有效。

12.11 S4 后续候选：创建者私有贯穿数据权利

团队共享服务器没有创建者私有、成员停用、个人导出或个人删除；以下规则只属于 S4 多用户产品。

• Conversation、Report 及其派生内容默认创建者私有；共享必须明确指定可见受众。成员基于他人共享内容创建的新对象归新创建者私有，既不扩大也不改变原对象的受众。读取、续读、下载、重试、分享和撤销都重新检查当前权限，旧链接和断连重连不能绕过撤销；撤销对后续服务端读取立即生效，但已经送达客户端或已经导出的副本无法收回，产品必须如实说明；
• Organization 管理员默认管理成员、能力、限制和汇总 Usage，不因此自动获得成员私有正文。平台运营日志也默认无正文；首批成员需要被如实告知平台运营在技术上仍可能接触底层存储，正常控制手段是最小权限、限时例外与留痕，而不是宣称技术上绝不可能。若未来确有支持、安全或法定义务下的内容访问，应采用这一例外流程，而不是普通管理功能；
• Telegram 群组是用户主动选择的共享 Surface。进入该 Surface 的内容对群组参与者及第三方平台可见，产品应在使用前明确提示；FinBayes 的撤回或删除不能承诺清除第三方已经保存的副本；
• 成员停用或移除后立即失去访问权，同时停止其登记的持续监测和定时任务，但不自动删除或转移其私有内容。已经显式共享的内容可按原受众继续可见，不因成员离开扩大范围；删除与保留按 Organization 已告知的策略执行；
• 导出至少覆盖本人创建的业务内容、必要元数据和共享状态，并形成一致快照；他人共享给本人的内容只呈现引用和可见性事实，不在个人导出中整体复制正文。删除先立即阻止继续访问，再由可续跑任务处理正文、派生内容和资产；备份按明确周期自然淘汰，恢复时重新应用删除记录，不能让已删除内容悄然复活；
• 客户内容、身份与控制数据、Usage / Cost / 安全审计事实、Secret 分别设置访问范围和保留期。运营事实只保留必要字段并尽量聚合或去标识，不因删除对话而伪造历史消耗从未发生；首批成员在加入前应清楚知道管理员和平台运营分别能看到什么。

12.12 S4 后续候选：从共享服务器进入多用户产品的准入门

共享服务器可以先在团队入口内持续收集真实金融 Case；只有后续多用户准入全部通过，才向独立身份开放私有资源：

1. 共享基线门：团队共享服务器的部署、队列、持久历史、恢复、网络和工具边界已通过真实运行验证；
2. 身份与入口门：成熟身份提供方、Membership、hosted AuthContext、AuthSession 撤销 / 寿命、local 回环保护、成员与部署级资源限制、无正文运营日志到位；Web 与 Telegram 等非 Web Surface 都必须先完成身份到 Membership 的绑定；
3. 私有运行门：Tenant 与对象级授权、创建者私有存储、持久 Conversation / Turn / Run / RunEvent / Result、工具最小权限、输入 / 输出安全处理、出站网络限制、文件工作区限定、Exec 关闭和 Provider 数据去向告知到位；备份已经配置且完成一次真实恢复演练，才允许首个真实 Run；
4. 共享能力门：显式受众、派生内容不扩权、撤销后重新鉴权、Telegram 共享提示和共享变更审计到位，才开放显式共享；
5. 里程碑验收门：断连恢复、重启与排空、幂等重试、迁移失败 / 部署回退 / 删除后的恢复、成员停用、导出 / 删除和越权负面测试均通过，才将 S4 多用户内测视为可持续基线。

这五道门只是 S4 阶段评审检查点，不是新的产品对象或 Runtime 状态机，也不反向阻塞团队共享服务器。合规导出接口、法务保留、客户自管密钥、数据驻留、完整 DLP、组织管理员内容审查、SSO / SCIM 和多 Organization 管理均可在真实需要出现后分批建设。

13. 模块与组件清单

进入阶段四时“整体要做什么”的一览。现状一栏对照当前主线代码，不是推测。

模块 / 组件	解决什么	现状	可参考	阶段归属
共享 Run 队列	Web / Telegram 同时提交时如何等待、显示位置、撤销和执行	已实现：Web / Telegram 共用 PostgreSQL 全局 FIFO 单执行槽，队列位置、撤销、中断和重启恢复已进入合同；待 Railway 联合验收	Codex task queue、Claude Code tasks / background work	S4 前置共享服务器核心
共享历史与运行登记	所有人看到同一份问题、回答、状态和来源	已实现：共享活动面汇总 Web / Telegram 的问题、状态和结果，权威 RunEvent 可跨进程重放；待真实双浏览器与 Telegram 群验收	Claude Code tasks / session recap、持久任务系统	S4 前置共享服务器核心
User / Principal / AuthContext	谁在使用服务、谁发起请求以及请求中的可信身份	已有固定 local Principal 与九字段身份信封，tenant_id 为 local 常量	AWS IAM Principal、OpenAI Organization User	共享服务器保持固定值；S4 再升级真实身份链
Organization / Tenant / Membership	产品协作空间、资源归属与隔离边界	Tenant 为固定 local 常量，尚无 Membership	Anthropic Organization / Workspace、Clerk Organization Membership	S4 新建最小关系；不引入 Workspace 层
身份接入	登录、凭证、外部身份对接	无	WorkOS、Clerk、Auth0	S4 新建（用成熟供应商）
请求上下文解析	每个请求的主体 / 租户裁决	有雏形（请求级身份信息 + 会话-主体绑定）	—	S4 改造升级
授权与工具安全	对象读取、共享、续读和 Agent 工具动作的统一准入	有统一 Permission 接缝、属主检查和工具副作用分类；已验证主体默认放行，无身份信封时根本不做裁决	AWS IAM、OWASP API / LLM Top 10	S4 hosted 内测准入
内部身份传播	子运行、监测与定时任务继承谁的身份和可见性	当前会自铸 system 主体并落入共享 base 工作区	AWS IAM Role Session、主流任务系统的发起者上下文传播	S4 hosted 内测准入
工具沙箱与出站网络	文件、命令和联网工具能接触什么	shared_server 已强制工作区限制、Exec 关闭、MCP 为空；联网抓取逐地址 / 重定向 / DNS 校验并钉住连接目标，拒绝本机、内网与云管理地址；待真实部署边界验收	OWASP SSRF Prevention、云平台元数据防护	共享服务器部署准入；S4 继续复用
会话与断连续读	刷新 / 断线后继续读事件	已有（单机形态验证过）	SSE 的 Last-Event-ID 约定	S4 保留地基、改存储
持久 Run 生命周期	浏览器断开不终止运行、诚实中断	已实现：HTTP 受理先持久化，queued 跨重启续跑，running 在重启或排空时诚实收为 interrupted，终态 Event / Result 同事务；待平台实证	OpenAI 后台运行；Temporal、Inngest	共享服务器先落地；S4 复用
服务端权威存储	队列、对话、回合、运行、事件与结果可恢复	已实现首版 PostgreSQL Conversation / Turn / Run / RunEvent / Result、幂等、队列和 Telegram 文本投递箱；workspace 文件与数据库通过冷备工具联合恢复；待 Railway 挂卷与恢复演练	PostgreSQL、持久任务账本	共享服务器核心；S4 再增加 Tenant 作用域
对象存储与上传资产	用户上传与大件产物	完全没有（全新能力）	OpenAI / Anthropic 的 Files 接口	S4 新建
结果解读	回答后的可选解读与显式重跑	已有（独立生命周期）	—	S4 迁移归属与存储
报告库	显式保存 / 标签 / 重开	已有	—	S4 迁移归属与存储
市场数据缓存	公共数据缓存与租户归因	已有（单机缓存）	—	S4 加租户归因
监控与定时任务	用户显式登记的监测	已有（单机）	—	S4 迁移归属
使用事实与成本归因	真实用量、内部成本与 Provider 对账	有部分 Provider token 回执、Run 汇总和安全估算，但缺完整尝试、统一归因与持久产品事实	OpenAI / Anthropic 组织级 Usage 与 Cost	S4 新建事实链，复用已有回执与 RunBudget
产品权益	此 Organization 能用什么	有 Permission 接缝，无 Entitlement	Stripe Entitlements	S4 建最小判断层，能力集合从简
资源限制	队列、部署、成员 / Tenant 上限多少	shared_server 已有全局单执行槽、32 条 queued 上限、12,000 字符 / 32 KiB 输入上限和只能收紧的 Run Budget；成员 / Tenant 级限制尚无	OWASP Unbounded Consumption	共享服务器先做部署级；成员 / Tenant 级进入 S4
隐私与数据权利	私有 / 共享、成员停用、导出、删除和保留	导出能力完全不存在；删除只覆盖报告正文文件和个别记忆条目，不覆盖对话、运行事件、结果与派生内容	OpenAI Business 数据控制、Anthropic 数据保留与合规接口	S4 hosted 内测准入与可运营能力
套餐 / 定价 / 支付	商业策略	无	—	后置
Web / API 资源合同	面向资源而非页面的服务接口	已有（按页面形状组织，需破坏性切换）	Anthropic / OpenAI 的 API 资源划分	S4 重划
Web 产品面	B/S 浏览器界面	已接入共享活动面、队列状态、结果读取与撤销 / 中断；待 Railway 双浏览器联合验收	Codex / Claude Code 的任务列表、状态与取消	共享服务器先加共享记录与队列；S4 再加登录 / 私有资源
部署与运维面	网络准入、迁移、备份、健康、告警与排空	Docker / Railway、/readyz、单实例租约、故障退出、信号排空、pre-deploy 和冷备恢复已落并通过离线合同；真实平台验收进行中	GitLab、Sentry、Supabase 的自部署实践	共享服务器核心；S4 继续深化

14. 参考与借鉴

按议题给出对照对象。方向性起点清单，细节在实施设计时复核。

议题	参考对象	看什么
共享任务队列与后台工作	OpenAI Codex 长任务队列实践、Claude Code Tasks / Background Work、Claude Code Agent View	提交与执行分离、等待 / 运行 / 完成状态可见、按任务停止、后台状态可恢复；FinBayes 首版选择单执行槽而非照搬并行 Agent
User / Principal / Organization / Tenant / Membership	AWS IAM Principal、Clerk Organization Membership、Anthropic Organization–Workspace、OpenAI Organization–Project	身份、授权主体、客户协作空间与内部隔离根如何分层
身份接入	WorkOS、Clerk、Auth0	自己不做密码 / 找回 / 风控的边界在哪
持久运行与断连恢复	OpenAI Responses 的后台运行与流恢复；Temporal、Inngest、Cloudflare Durable Objects	成熟做法，以及它们明确不承诺什么（任意中点恢复、精确一次副作用）——与 §7.2 的不承诺清单相互印证
对话对象建模	OpenAI 从 Assistants / Threads 收回到 Responses 的调整	反面教材：对话对象过度建模的代价
事件续读	SSE 的 Last-Event-ID 约定	现有实现已有等价游标，不要另造一套语义
存活、就绪与排空	Kubernetes Probes、Pod Lifecycle	存活、就绪与终止宽限各自回答不同问题；参考其语义分工，不要把 FinBayes 绑定到 Kubernetes
备份与时间点恢复	PostgreSQL PITR	权威数据如何恢复到可验证的一致点；恢复演练不能被“已开备份”替代
文件与资产	OpenAI Files、Anthropic Files	上传—引用—生命周期—配额的最小形状
数据隔离	PostgreSQL 行级安全 vs 每租户 schema；Supabase、Neon 的取舍	隔离强度与运维复杂度的换算
用量、成本与权益	OpenAI Usage / Costs、Anthropic Usage and Cost API、Stripe Entitlements、Stripe Meters	分开看实际消耗、内部成本、产品能力与未来商业计量；印证“权益不后置、定价后置”，也不把所有 Usage 预先改造成计量事件
Agent 资源与权限边界	OWASP LLM10 Unbounded Consumption、Excessive Agency 与 Sensitive Information Disclosure	公网可达的 Agent 在内测前就需要速率 / 并发 / Run Budget、最小权限、敏感数据不进日志，不等待商业化
对象级授权	OWASP API1 Broken Object Level Authorization	每次通过 ID 读取、续读、下载、重试、分享或撤销资源时都重新检查当前主体与对象关系
出站网络边界	OWASP SSRF Prevention、云平台元数据服务防护	模型驱动的 URL 抓取不能访问本机、内网和云管理地址，跳转后也不能绕过
限时特权访问	OpenAI / Anthropic 的企业内容访问与合规接口实践、主流 break-glass 管理	正常管理员不读私有正文；支持、安全或法定义务下的例外必须最小权限、限时和留痕
私有内容与数据生命周期	OpenAI ChatGPT Business 隐私说明、OpenAI 托管账户说明、Anthropic API 数据保留、Anthropic 合规内容接口	私有历史、显式共享、管理员可见性、内容与运营事实分层保留，以及软删除 / 最终删除的真实边界
云端 + 自部署同源	GitLab、Sentry、Supabase	一套代码同时供云端与自部署、不分叉的具体做法

15. 交付阶段拆解

阶段四前置里程碑：团队共享服务器基线

这不是另一套产品或临时分支，而是同一代码主线从本地开发走向服务端持续运行的第一步。以下六个小批次中，前五项及第六项的本地实现 / 离线合同已经完成；当前只剩 Railway 真实部署与团队联合验收：

1. 共享模式合同：明确无 FinBayes 登录、一个共享工作空间、固定共享认知资产范围、Web 为完整共享记录、Telegram 只在指定群内响应；local 模式继续只绑定回环地址；
2. 共享状态持久化：队列、幂等窗口、Conversation、Turn、Run、RunEvent、Result 与 Telegram 文本投递箱成为 PostgreSQL 权威记录；共享活动与事件回放从这些事实生成，Interpretation、Report 与其他 workspace 资产仍由现有存储和联合冷备覆盖。启动时幂等对账：活动 Run 转为 interrupted，等待项重新入队；
3. 统一任务队列：在 Web 与 Channel Adapter 之下建立同一个全局 FIFO 准入与运行控制面，首版并发数为 1；显示等待顺序，按 Run 统一处理排队撤销与运行中断，不能继续由 Web 和 Telegram 各自维护任务；
4. Web 共享工作面：在一个页面查看 Web 与 Telegram 发起的提问、回答、队列和运行状态；刷新、断线和重启不丢已确认记录；
5. Telegram 群接入：只接受指定群，群内通过 @FinBayes 提问；所有群成员使用同一共享空间，不再按发送者拆分认知资产；
6. 部署与团队验收：显式 server profile、就绪、排空、备份恢复和全局资源上限已经落地；团队成员正在 Railway 配置真实持久卷、Secret 与边缘入口，随后完成真实多人 Web + Telegram 验收。

依赖关系仍是“权威状态 → 队列 → 两端呈现 → 团队开放”。前三段已有本地与 PostgreSQL 离线证据；最后的团队开放必须以真实 Railway、双浏览器和 Telegram 群证据为准，在此之前不宣布基线可用。

阶段四第一阶段：多用户服务产品化

在共享基线积累真实金融场景后，再引入登录、User / Principal / Organization / Tenant / Membership、创建者私有与显式共享、对象级授权，以及相应的 Web / API 一次性重划。共享服务器模式继续作为同一代码中的 deployment profile，不被复制或废弃。

阶段四第二阶段：可运营与商业承载地基

完善 Tenant 级隔离、用量与成本事实、产品权益、成员 / Tenant 资源限制、部署运维和数据生命周期。价格、套餐和支付仍不进入这一阶段的 Runtime 前置条件。

后续阶段：商业模式落地

只有获得真实市场证据后，才引入 Meter / Metered Usage、Subscription、Price、套餐、促销、支付、退款与合同；商业规则映射为 Entitlement，不反向改造 Runtime。

16. 任务清单与推进顺序

16.1 已批准方向：团队共享服务器基线

1. 固化 local 与“团队共享服务器”两种部署模式及其边界；
2. 用单实例 PostgreSQL 建立共享队列、幂等窗口、Conversation / Turn / Run / RunEvent / Result 与 Telegram 文本投递箱的权威存储；共享活动与事件回放从这些事实生成。Interpretation、Report 和其他 workspace 资产继续沿用现有存储，并通过联合冷备覆盖，不在共享基线中假称已经数据库化；
3. 建立 Web / Channel 共用的全局 FIFO 与按 Run 运行控制：单任务运行、等待顺序、排队撤销、运行中断，以及启动时 active → interrupted、queued → 重新入队 的幂等恢复；
4. 将 Web 调整为所有入口的共享队列、历史与结果工作面；
5. 将 Telegram 准入从逐个 sender 调整为指定 chat：群内任何成员可通过 @FinBayes 提问，其他群被拒绝；保留紧急 sender denylist，使用固定共享认知资产范围并记录写入来源；
6. 建立显式服务器监听、Host / Origin 限定、团队网络 / 边缘准入、共享服务凭证和服务端 Secret 注入；
7. 建立就绪 / 排空、备份恢复、输入 / 输出 / 队列 / RunBudget 上限、文件与出站网络边界，Exec 默认关闭；
8. 用至少两个浏览器参与者和一个真实 Telegram 群完成并发排队、撤销、断线、重启与恢复验收。

方向已经获得 owner 确认，Roadmap 实施任务已拆解；本地实现、离线测试、Docker / PostgreSQL 合同与部署交接已经完成。团队成员正在 Railway 执行真实部署，§17.1 的平台与多人联合验收通过前，仍只称“基线候选”，不把它标为已完成。

16.2 阶段四后续任务

1. 固化 User / Principal / Organization / Tenant / Membership 与私有 / 共享资源关系；
2. 接入身份提供方并形成 AuthContext，不新造第二套身份词；
3. 按目标资源图一次性重划 Web / API，并替换保留的消费者；
4. 建立 Tenant 强制隔离、创建者私有、显式共享与越权负面测试；
5. 建立 Tenant 级 Usage / Cost、Entitlement、资源限制与数据生命周期；
6. 将 InputAsset、对象存储和其他后置模块按真实场景独立排期；
7. 获得市场证据后再设计套餐、定价、促销、支付和复杂商业计量。

17. 阶段验收草案

17.1 团队共享服务器基线

• 打开 Web 即可使用，不出现 FinBayes 用户登录、Membership 或个人空间；服务只能从获准的团队网络 / 边缘入口访问，未获准入口被拒绝；
• 不同浏览器看到同一队列、同一提问与回答历史、同一运行状态和结果；
• 指定 Telegram 群可通过 @FinBayes 提问，其他群被拒绝；Web 能看到 Telegram 发起的任务，Web 提问默认不自动广播到 Telegram；
• 多个问题同时到达时按全局 FIFO 等待，首版只运行一个任务，并显示等待顺序；
• 任何已获准参与者都能撤销排队任务；运行中任务只能得到真实的 interrupt / terminal 结果，不能伪造成功或取消；
• 两个不同浏览器会话可以互读同一运行事件；Web 可中断 Telegram 发起的运行，Telegram 也可按共享 Run 控制规则停止 Web 发起的运行；
• 队列、幂等窗口、Conversation / Turn / Run / RunEvent / Result 与 Telegram 文本投递在刷新、断线和服务重启后仍可恢复；Interpretation、Report 与其他 workspace 资产由联合冷备覆盖。重启时运行中的任务记为 interrupted，尚未运行的任务继续等待，重试不会生成重复执行；
• 指定 Telegram 群内未单独配置过 sender 的普通成员可以提问，其他群与紧急 denylist 中的 sender 被拒绝；
• 备份恢复、部署排空、存活 / 就绪检查和故障回退至少完成一次可复现演练；
• 输入、输出、队列长度、运行时长 / RunBudget 有部署级上限；文件工具不能越出工作区，出站抓取不能访问本机、内网或云管理地址，Exec 默认关闭，凭证不进入 prompt、事件、结果或普通日志；
• 至少使用两个独立浏览器参与者和一个真实 Telegram 群完成并发提问、排队、撤销、断线、重启和恢复验收。

17.2 阶段四多用户产品化

阶段四再验收登录、Tenant 强制隔离、创建者私有与显式共享、成员生命周期、对象级授权、Tenant 级 Usage / Cost / Entitlement、数据导出 / 删除，以及 Web / API 一次性重划。它们不反向成为共享服务器基线的准入条件。

18. 当前推进顺序

1. 保持 Roadmap、Atlas 与本草案对当前事实一致，不把本地绿灯提前写成真实部署通过；
2. 由团队成员完成 Railway 部署，以及真实挂卷、Secret、入口、信号、双浏览器和 Telegram 群联合验收；
3. 概念 / 命名治理准入与 Web / API 五项切换包已经批准；Railway 验收结果回写后，直接拆出阶段四多用户第一实施切片；
4. 阶段四按身份入口、私有运行、显式共享和可运营能力的里程碑顺序推进；
5. 继续用共享基线收集真实金融场景；获得市场证据后再讨论套餐、定价、促销和支付。

19. 变更记录

日期	状态	讨论收敛
2026-08-21	S4 概念与 Web / API 开工准入通过	消除产品正本把无登录共享服务器误写成 S4 多用户里程碑的漂移；冻结规范关系、禁用裸词与触及时迁移处置。Web / API 五项切换包获批：现有保留 Web 能力全部迁移后才退出 /workbench/*，InputAsset 后置，Case / Projection / Task 页面形状不自动升级为产品本体；安全反向验收进入整包出口
2026-08-21	共享服务器进入 Railway 部署与联合验收	同一主线的 PostgreSQL 权威状态、全局 FIFO、Web 共享活动面、Telegram 文本投递箱、服务器安全与资源边界、/readyz、排空、pre-deploy 和冷备恢复均已落地；真实 PostgreSQL 17 离线合同 34/34。部署交由团队成员执行，真实挂卷 / Secret / 平台信号 / 边缘准入 / 双浏览器 / Telegram 群验收仍为 S4 前置门，不提前标绿
2026-08-21	共享服务器方案完成对抗复核	Claude Opus 5 定点核对 Web、Telegram、Runtime 与三份方案文档；补齐跨 Surface 统一取消 / 中断、幂等窗口与启动恢复对账，并确认共享活动与恢复必须有权威事实来源。首版实际以 PostgreSQL Conversation / Turn / Run / RunEvent / Result 与 Telegram 文本投递箱为权威账，Interpretation / Report 等 workspace 资产由联合冷备覆盖；Telegram 以指定群成员关系准入并保留紧急 sender denylist
2026-08-19	草案建立	付费模式与定价后置；S4 定位为商业模式中立但商业化就绪的服务产品化；明确 usage / cost 与权益判定不后置
2026-08-19	部分保留	保留“客户空间业务状态强制 Tenant 作用域”；其中 Account 授权主体与默认 personal Tenant 已由 2026-08-20 概念准入撤销
2026-08-19	已定	浏览器断开不终止 Run；无法继续时标记 interrupted；用户显式重试创建新 Run；首版不承诺自动接管与任意中点恢复
2026-08-19	已定	首版完整运行事件进入 PostgreSQL，按 Run 内顺序编号；不预建“关系索引 + 对象日志”冷热双存储
2026-08-19	已定	local profile 首版保留文件存储 Adapter，显式绑定固定 local Tenant，不引入 SQLite；云端与 local 以共享合同和 Adapter 测试对齐
2026-08-19	修订	明确体裁定位（已定）：本文收束为目标 / 概要架构 / 议题 / 模块 / 阶段拆解与参考借鉴，不做工程实施设计。吸收 Claude Code 对照主线代码的评审：授权主体定名冲突（待决，提为首个收敛项）、Run 状态词沿用现有集只补“中断”（候选）、网络暴露为显式准入（候选）、模块清单补结果解读与报告库、上传资产标注为全新能力、API 资源化为破坏性切换并收编四个接口缺口（候选）、使用事实须来自真实回执（候选）。新增“模块与组件清单”与“参考与借鉴”两章；交付切片改用可读名称；待决议题顺序把名词与状态词收敛提为第一位
2026-08-19	部分撤销	Account 授权主体结论已由 2026-08-20 概念准入撤销；Run 状态词沿用现有状态集、仅新增 interrupted 的结论继续有效
2026-08-19	已定	存储边界四问收敛：过程记录与结果同寿命；先存大文件后记“完成”，杜绝“显示成功但内容丢失”；首版单实例但运行状态以数据库为准、不写死单机；Tenant 删除 / 导出为立即封禁访问、可查进度、可续跑的后台任务
2026-08-20	概念与命名准入收敛	撤销 Account 作为授权主体和 personal Tenant 默认模型；确定 User / Principal / AuthContext / Membership / Organization / Tenant 分层；S4 不引入 Workspace、Project、Personal Space；Account、Session、Event、Usage、Credit 等裸词禁用或限定
2026-08-20	已定	Conversation / Report 默认创建者私有、显式共享；明确共享 Surface 可声明共享受众，派生结果不得扩大可见范围；S4 不设计多 Organization 统一付款或 Billing Customer，等真实企业合同再引入独立关系
2026-08-20	Web / API 目标边界收敛	API 目标设计与迁移验收前置到 S4 开工准入，工程重划进入 S4 第一实施切片；Web 是首个 HTTP 迁移面，CLI / TUI / 渠道不强制绕 HTTP；目标按 AuthSession、Conversation、Turn、Run、RunEvent、Result、Interpretation、Report、InputAsset 等稳定资源组织，旧 /workbench/* 在全部保留消费者迁移后一次性退役
2026-08-20	当前 Web / API 基线恢复	Interpretation 单次读取、Report Library、Capabilities 已在服务、Web、OpenAPI、Handbook、生成类型和合同测试间恢复一致；未抢跑 Conversation 读取或 AuthSession 新接口
2026-08-21	Web 呈现基线与切换包收敛	已收敛失败语义、解读快照、报告库入口、交互联动与三语文案，Web 84 个测试文件 / 817 项测试通过；新增团队评审用五项切换包，保持产品级粒度，不提前写实施细节
2026-08-21	已被后续纠偏替代	曾把第一台服务器误写为“邀请制 Organization + 成员独立身份”的 S4 hosted 里程碑；本行仅保留讨论轨迹，不再作为当前方案
2026-08-21	owner 纠偏：团队共享服务器基线	第一台服务器位于 S4 多用户化之前：无 FinBayes 登录、固定共享空间、Web 与指定 Telegram 群共用运行与历史、全局 FIFO 单执行槽、队列可见可撤销、状态跨重启恢复；网络准入与服务凭证仍保留，但不建立 User / Membership / Tenant 管理。与后续 S4 共用一套代码和 Runtime
2026-08-21	owner 批准升级、就绪与恢复合同	批准单实例排空、存活 / 就绪 / Run 准入分离、权威数据一致恢复、hosted Trace 默认关闭和内测前资源边界五项合同；团队内测初始恢复目标为 RPO ≤ 1 小时、RTO ≤ 4 小时
2026-08-21	部分后移	Usage / Cost 的部署级事实与全局 Limits 可随共享服务器建立；Entitlement、Tenant / 成员归因与 Visibility 进入 S4 多用户产品。Provider 调用尝试仍是最小事实，unknown、estimated 与 Provider 回执严格分开，套餐、定价、支付和 Billing Credit 继续后置
2026-08-21	部分后移	出站网络、文件工作区、模型输出处理、Secret 与资源边界仍是共享服务器准入；Membership、对象私有、成员停用、个人导出 / 删除等整体后移到 S4 多用户产品
2026-08-20	已被后续纠偏替代	“登录—私有对话—显式共享”继续作为 S4 多用户首切片，但不再是第一台服务器的实施起点；共享服务器先贯通入口、队列、运行、共享历史、恢复与 Web / Telegram
2026-08-19	已定	首版登录方式只做邮箱验证码与 Google 一键登录，不做密码体系，短信后置；登录服务商选型留实施期，标准为可替换、不锁死用户数据、支持自部署；本地版不设登录，保持打开就用