SPEC_deepview_metadata_scoping_v3: Prosumer-First Isolation & Inbox-Driven Architecture

1. 核心设计理念

本 SPEC 正式废除了 V2 版本的“多租户混存 (Client Public)”与“前置强绑定 (Eager Binding)”模型。在 Deepview 面诊场景下，我们全面转向以 "个人生产力优先 (Prosumer First)" 和 "惰性归档 (Lazy Binding / Inbox Mode)" 为核心的底层架构体系。

1.1 Prosumer First：个人优先的极端数据沙箱

历史痛点：传统的由上至下 (B2B Top-Down) 的 CRM 系统，客户档案库公有共享，存在高危的数据越权（看到别人客户）与交叉污染流（误点归档给别人客户）的致命风险漏洞。
重构准则：
- 物理隔离：所有的客户端存储不再挂载于公共的 storage/clients/ 目录下。系统的第一物理和逻辑边界，被极端下沉至当前账号标识（通过认证 Token 提取的 userId）。一切数据发生、停驻、流转，仅在 storage/users/{userId}/ 沙箱内进行。
- 个人资产，天然互斥：李大夫（userId: doc_001）所录的音、所建的档“张女士”，与王主任（userId: doc_002）毫无干系。在获取客户列表 API (/clients/list) 或归档选取时，从底层文件系统级杜绝泄密和错误指派。
未来演进：企业的资产全局管控，应当仅作为“上层看板授权联邦拉取”，而不应去干扰底层的物理独立沙箱。

1.2 Inbox-Driven：零摩擦采集与天然防幻觉机制

历史痛点：医疗场景下医生极度繁忙。如果录音/上传照片动作前必须等待医生点选“这是一个谁”，哪怕点 3 下，系统的使用率也会趋近于零。若提前强行注入该客户的错乱 <Client_Profile>，还会引导模型产生幻觉。
惰性状态机：
- 降落点 (Landing)：医生只需要“一按即录”，或“长按即传”，全程无任何表单阻塞。这些产生的原材料以及转写而来的 ASR 记录，强制落位于 storage/users/{userId}/inbox/{reportId} 中。
- 裸推演 (Naked Deduction)：在报告生成（Generate）环节，严禁注入任何先验的客户 Profile。大模型仅凭借对常理常识的判断与录音中真实发生的事实推断。此时，一切结果都是绝对真实可信的。
- 事后绑定 (Lazy Archive)：只有在医生事后审核通过报告后，点击归档横幅，引擎才会通过原子操作（os.rename）将本次全本推演数据包物理转移至 storage/users/{userId}/clients/{clientId}/history/ 生效。

2. 核心 API 与动作流转约束

2.1 获取/过滤极简入口

所有的 UI 操作流派，其前端不需要去思考租户边界。系统核心交互降级至底线直连流态：

短按（录音启动）：无论界面长什么样，按下按钮的瞬间即刻推包给流式 websocket 服务。无表单阻拦。
长按（归档上传）：立刻弹起原生系统相册选择控件，选完即进 Inbox 走裸推演流。

2.2 归档横幅管控策略（Archive API）

对于处于 Inbox 态的报告记录：

在界面必须强制用 ⚠️ 等醒目样式标识状态为：【尚未归档到具体客户】。
调用 POST /deepview/reports/archive 端点时，后端必须履行：
1. 校验目标沙箱路径合法性 (storage/users/{userId}/clients/...)。
2. 实现原子文件迁移。
3. 执行 UPDATE deepview_reports_v2 SET client_id = ? ... 更新落盘。

3. Prompt 防线与大模型能力解绑

去除 doctorName 迫使生成：因为“面诊主治医师”现在是 100% 绑定于当前登录者的业务行为，我们在 Stage 2 的 JSON schema 中，严禁要求大模型瞎猜/编造 doctorName 字段。所有这类操作全部交由前台通过 auth.user() 会话来强行烙印，彻底挤干被动幻觉引发的每一个水分子。
Speaker 脱敏指代：推演必须根据真实的语义去识别 Speaker_[X]。如果在未建档的情况下无法直接写出原名，就忠厚老实地写“该位女士/客户/面诊者”。

本规范为深维医生助理 V3 核心底座大纲，自立项归档后，取代其他过去的一切数据互斥妥协案。

4.2 KiB Raw Permalink Blame History Unescape Escape