docs: restructure to Prosumer-First & Inbox-Driven Architecture (V3)

docs/SPEC_deepview_metadata_scoping_v2.md

@@ -1,33 +0,0 @@
-# SPEC_deepview_metadata_scoping_v2: Single-Stage Auto-Roles & Data Isolation
-
-## 1. 核心设计理念
-
-本 SPEC 定义了 deepview-agent 在面诊场景下的“极简交互”与“数据边界隔离”两大设计原则。
-
-### 1.1 一镜到底与角色天然反推 (Single-Stage & LLM Auto-Roles)
-- **痛点**：医疗场景下医生争分夺秒，不能提供复杂表单填写；让助理听录音指定角色存在主观偏见且增加负担。
-- **解法**：在面诊流转前（短按录音/长按上传时），**唯一**强制交互仅为“选择/录入本次面诊客户 ID”。录音一旦上云，ASR（分离说话人为 Speaker_X）和 LLM（内容战略分析）自闭环进行。
-- **神来之笔**：在大模型的 Prompt 中，不需要人类干预，通过提供 `<Doctor_Profile>` 和 `<Client_Profile>` 两个先验事实文档，让 LLM 根据长文本语境（谁在做科普、谁在表现疼痛抗拒）100% 天然反推出各 Speaker 所对应的真名角色。
-
-### 1.2 资产库公域化，实战卷宗私有化 (Client Public, Session Private)
-针对“一个客户看多个同院医生”的机构边界隔离：
-- **公共履历资产 (Client Profiles)**：
-  - `storage/clients/{clientId}/profile.md` 是机构公共资产库。
-  - 所有医生的面诊洞察均在此累加。大模型脱敏记录“客户性格”、“痛感耐受度”供全院参考。
-- **私下面诊防壁 (Session Isolation)**：
-  - 面诊原声录音 ASR、深打面诊生成报表，通过 `user_id` （MindPass token 里的 JWT sub）被数据库强隔离。
-  - 只有主诊医生 (当前 account) 拥有拉取该报表 (`deepview_reports_v2`) 和该期录音溯源的权限，保障医疗隐私与个人业务壁垒。
-
-## 2. 交互流转映射
-1. **短按（实时面诊）**：
-   - 唤起【客户选择器】半屏弹窗
-   - 用户检索/输入（例如：李女士 尾号8812），点击开始
-   - 面板回缩，**立即激活麦克风**进入常驻录音流态。结束时一键送云。
-2. **长按（归档上传）**：
-   - 唤起【客户选择器】半屏弹窗
-   - 确认客户后，调取原生相册文件选择器。
-   - 文件选中后直接上兵云端进行转写推理闭环。
-
-## 3. 技术约束与 Prompt 保障
-在 `_handleReportGenerate` 中，系统会拼接两份不可变的 DB 文件作为 Context，然后发出以下硬约束指令：
-> *请自动根据对话语境推断哪位发声者是面诊医生（名医建档：[医师库]），哪位是客户（客户建档：[客户库]）。切勿向我请示或询问，直接在最终的面诊战术建议和信任度量中以真实姓名行文替代这些无感情的 Speaker。*

docs/SPEC_deepview_metadata_scoping_v3.md

@@ -0,0 +1,41 @@
+# 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 操作流派，其前端不需要去思考租户边界。系统核心交互降级至底线直连流态：
+1. **短按（录音启动）**：无论界面长什么样，按下按钮的瞬间即刻推包给流式 websocket 服务。无表单阻拦。
+2. **长按（归档上传）**：立刻弹起原生系统相册选择控件，选完即进 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 核心底座大纲，自立项归档后，取代其他过去的一切数据互斥妥协案。*