feat(rvw): complete journal config center MVP and tenant login routing

Deliver the RVW V4.0 journal configuration center across backend, frontend, migration, and docs with zh/en editorial baseline support and tenant-level prompt/template overrides. Unify tenant login to /:tenantCode/login and auto-enable RVW module when tenant type is JOURNAL to prevent post-login access gaps.

Made-with: Cursor

docs/03-业务模块/RVW-稿件审查系统/08-技术架构建议/ADMIN多业态租户架构演进评估 (1).md

@@ -0,0 +1,117 @@
+# **ADMIN 运营管理端：多业态租户架构演进评估与设计指南**
+
+**文档定位：** 针对平台未来面临“医院、药企、期刊”三大业态分化的战略级架构指导文件。
+
+**核心主旨：** 摒弃“上帝级”通用租户配置页，走向\*\*“数据底层大一统，前端展现分而治之”\*\*的 SaaS 演进路线。
+
+**评估结论：** 强烈建议将“期刊配置中心”在前端作为独立一级菜单和页面独立出来。
+
+## **🔍 一、 业务形态分化趋势评估**
+
+平台目前服务的三类客户，其核心诉求与配置维度已经发生根本性分化：
+
+| 业态类型 | 核心业务模块 | ADMIN 端的配置侧重点 | 运营人员视角 |
+| :---- | :---- | :---- | :---- |
+| **医院 / 科研机构** | IIT (研究项目), DC (数据清洗) | REDCap 数据源打通、CRA 质控规则、伦理审查合规性、患者隐私脱敏级别。 | 偏向于“项目制”与“数据安全”管理。 |
+| **药企 / 申办方** | PKB (企业知识库), AIA (智能体) | 专属知识库的向量化参数、RAG 检索阈值、多智能体协作 Prompt、合规审查界限。 | 偏向于“知识资产”与“AI 能力”调优。 |
+| **医学期刊编辑部** | RVW (智能审稿) | 稿约规范双语基线、方法学/临床评估 Prompt 编排、Handlebars 退修信模板定制。 | 偏向于“审稿流水线”与“千刊千面”排版。 |
+
+**评估意见**：如果未来继续在同一个 TenantDetailPage.tsx 里通过 if-else 来堆砌这些表单，前端代码将迅速腐化，且运营人员在配置一家期刊时，可能会被医院的 REDCap 配置项干扰。**前端页面的物理拆分势在必行。**
+
+## **🏛️ 二、 核心架构建议：底层统一，表层分治**
+
+为了兼顾“开发成本”与“运营体验”，建议采用以下架构模式：
+
+### **1\. 底层大一统 (Unified Data Model)**
+
+**不能把租户表拆散**（不能建 journal\_tenants, hospital\_tenants）。
+
+* **原因**：全平台的统一登录 (SSO)、统一计费 (Quotas)、基础信息 (Logo、名称) 必须保持全局唯一，复用现有的 platform\_schema.tenants。  
+* **改造动作**：在 tenants 表中新增一个核心的枚举分类字段 tenant\_type。
+
+### **2\. 1对1 扩展表 (1-to-1 Extension Tables)**
+
+针对不同业态的独特配置，采用垂直分表的模式，保持主表整洁。
+
+* 期刊配置存入 tenant\_rvw\_configs  
+* 药企配置存入 tenant\_pkb\_configs (未来)  
+* 医院配置存入 tenant\_iit\_configs (未来)
+
+### **3\. 前端分治 (Decoupled Frontend Views)**
+
+在 ADMIN 端的左侧菜单，明确区分业务管理入口，为特定业态打造沉浸式的配置体验。
+
+## **💾 三、 数据库 Schema 调整落地 (Prisma)**
+
+基于上述思路，在 MVP 阶段的数据库改造应如下进行：
+
+// 1\. 定义租户业态枚举  
+enum TenantType {  
+  CLINICAL    // 医院/科研机构 (默认)  
+  PHARMA      // 药企/申办方  
+  JOURNAL     // 医学期刊  
+  INTERNAL    // 内部平台测试  
+}
+
+// 2\. 改造基础租户表  
+model Tenant {  
+  id              String      @id @default(uuid())  
+  code            String      @unique // slug  
+  name            String  
+  tenantType      TenantType  @default(CLINICAL) // 新增：业态分类  
+  journalLanguage String?     // 'ZH' | 'EN' (仅当 type=JOURNAL 时有效)  
+    
+  // 关联扩展表  
+  rvwConfig       TenantRvwConfig?  
+  // pkbConfig      TenantPkbConfig?  (未来扩展)  
+    
+  @@schema("platform\_schema")  
+}
+
+// 3\. 期刊专属扩展表 (保持不变)  
+model TenantRvwConfig {  
+  id       String @id @default(uuid())  
+  tenantId String @unique  
+  tenant   Tenant @relation(fields: \[tenantId\], references: \[id\])  
+  // ... Prompt 和 Template 字段  
+}
+
+## **🖥️ 四、 前端展现独立化设计方案 (ADMIN UI)**
+
+在之前的审查中，我曾建议“砍掉独立的期刊配置中心，回归租户详情页”。**在此，基于您的战略预判，我正式推翻该建议，支持您最初的构想：在前端建立独立的《期刊配置中心》。**
+
+### **1\. 左侧导航重构**
+
+ADMIN 端的导航栏应当按“业态垂直管理”和“平台横向管理”进行划分：
+
+▼ 平台横向管理 (横向能力)  
+  \- 🏢 基础租户池 (所有租户的大盘，仅管理基础信息和计费)  
+  \- 👥 全局用户与权限  
+  \- 🎨 Prompt 基础设施
+
+▼ 垂直业态中心 (深度定制)  
+  \- 🏥 临床研究中心配置 (过滤 tenantType=CLINICAL)  
+  \- 💊 药企知识库配置   (过滤 tenantType=PHARMA)  
+  \- 📖 期刊 SaaS 配置中心 (过滤 tenantType=JOURNAL)
+
+### **2\. “期刊配置中心”的专属交互设计**
+
+点击【期刊 SaaS 配置中心】后，前端交互应与普通租户管理区分开：
+
+* **列表页 (JournalConfigList)**：  
+  * 后端 API 依然调用 GET /api/admin/tenants，但前端强制带上参数 ?type=JOURNAL。  
+  * 列表直接展示期刊专属的列：期刊名称、访问路径(Slug)、语言基线、AI 审查模块开关状态。  
+* **新建期刊向导 (Creation Wizard)**：  
+  * 点击“新增期刊”，不要弹出普通租户那种几十项配置的抽屉。  
+  * 弹出专属向导：第一步填名称和 Slug，第二步选“中文核心/英文 SCI”，第三步自动为其绑定 RVW 模块权限，一气呵成。  
+* **沉浸式配置页 (JournalConfigDetail)**：  
+  * 左侧是“稿约、方法学、数据、临床” 4 个锚点导航，右侧是您要求的“大文本框 Prompt \+ Handlebars 预览”，完全为期刊实施人员打造，没有任何多余的干扰信息。
+
+## **🚀 五、 给 MVP 开发计划的修正建议**
+
+您可以直接把这份文档同步给开发团队，并对之前的《MVP 开发计划》做如下调整指示：
+
+1. **DB 调整**：必须在 tenants 表新增 tenant\_type (Enum) 字段，以此作为划分业态的唯一真理。  
+2. **前端放行**：**恢复执行 FE-1 (新增左侧一级模块) 和 FE-2 (独立的期刊列表页) 任务！** 3\. **接口复用**：前端虽然拆了页面，但后端**不需要**写两套 CRUD。列表查询依然用 /api/admin/tenants?type=JOURNAL，配置更新依然用 /api/admin/tenants/:id/rvw-config。
+
+**总结：** 您的这个决定避免了系统在未来半年内演变成一个庞大而混乱的“怪物”。通过**数据层的强内聚**（共享 Tenants 表和 SSO）与**前端页面的强解耦**（独立业务配置中心），平台将具备极强的横向扩展能力！

docs/03-业务模块/RVW-稿件审查系统/08-技术架构建议/期刊配置中心MVP计划审查报告.md

@@ -0,0 +1,76 @@
+# **RVW V4.0 期刊配置中心 MVP 开发计划 \- 架构与工程审查报告 (V2.0 战略更新版)**
+
+**审查目标：** 评估《RVW V4.0 期刊配置中心 MVP 开发计划 v1.0》的技术可行性、与平台多业态（临床/药企/期刊）演进架构的对齐度，以及潜在的生产环境风险。
+
+**审查结论：** 计划整体逻辑清晰，**前端独立拆分模块（FE-1, FE-2）的战略方向极具前瞻性**。但在 **底层业态标识、数据库平滑迁移、防呆设计缺失** 等方面存在 5 个关键问题，需在进入开发前紧急修正。
+
+## **🟢 核心架构亮点 (Architecture Gold Standard)**
+
+### **1\. 优秀的前端解耦：独立的期刊配置中心**
+
+* **计划现状**：任务 FE-1 和 FE-2 提出要“新增左侧一级模块（期刊配置中心）”和“新增列表页”。  
+* **审查意见**：**极度赞同！** 随着平台演进，医院、药企、期刊的配置诉求将天差地别。将期刊配置从拥挤的通用 TenantDetailPage 中剥离出来，建立独立的沉浸式工作台，是极其健康的 SaaS 演进路线。  
+* **⚠️ 后端防坑提醒**：虽然前端页面拆分了，但**后端绝对不能拆分新建独立的期刊租户表**。接口必须深度复用 GET /api/admin/tenants，通过下文提到的 tenant\_type 参数进行动态过滤。
+
+## **🔴 高风险项 (P0级 \- 影响系统稳定与架构基线)**
+
+### **2\. 业态类型缺失：如何从底层区分“期刊”与“医院”？**
+
+* **计划现状**：将所有配置加在了全局的 tenants 表关联中，但没有明确区分租户种类的字段。  
+* **冲突点**：前端要实现独立的“期刊列表页（FE-2）”，后端数据库中现有的临床租户和期刊租户目前混在一起，无法高效过滤。  
+* **修正建议**：  
+  在 platform\_schema.tenants 表中，**必须**新增一个业态分类枚举字段：  
+  enum TenantType {  
+    CLINICAL  
+    PHARMA  
+    JOURNAL  
+  }  
+  // 在 tenants 表中新增：  
+  tenantType TenantType @default(CLINICAL)
+
+  只有 tenantType \=== 'JOURNAL' 的租户才会出现在期刊配置中心的列表中。
+
+### **3\. 数据库迁移雷区：向已有表强加非空字段导致 Migrate 崩溃**
+
+* **计划现状**：计划 4.2 A 节要求向已有的 platform\_schema.tenants 表新增 journal\_language 和 journal\_full\_name，且要求非空。  
+* **冲突点**：线上数据库中 tenants 表已经存在历史数据（主站租户、IIT租户等）。如果直接执行 ALTER TABLE ADD COLUMN journal\_language TEXT NOT NULL，Prisma 会因为历史记录缺少该字段的默认值而直接报错中断。  
+* **修正建议**：  
+  在 BE-1 的迁移策略中必须指明平滑过渡方案，建议二选一：  
+  * **方案 A（推荐）**：在 Schema 中将该字段设为必填并给定默认值 @default("ZH")，或对于非期刊租户允许其具有特定默认值。  
+  * **方案 B**：设为可选字段 String?，在业务代码（Controller/Zod层）强制要求对于 tenantType \=== JOURNAL 的记录非空拦截。
+
+## **🟡 中风险项 (P1级 \- 影响开发体验与业务闭环)**
+
+### **4\. 致命防呆设计丢失：Handlebars“测试渲染”预览功能被遗漏**
+
+* **计划现状**：任务 FE-3 仅规划了“每个维度 Prompt \+ Handlebars Template 文本框”。  
+* **冲突点**：让运营人员在干巴巴的文本框里盲写 Handlebars 代码是灾难性的。一旦写错括号 {{ 导致线上渲染白屏，客诉极大。  
+* **修正建议**：  
+  必须在 FE-3 中加回 **“测试渲染 (Test Render)”** 按钮。要求前端复用 ADMIN 现有的 PromptEditorPage 中的 Mock 预览机制，在右侧提供实时 Markdown 预览面板。（此功能是 All-in-Prompt 架构的风控底线）。
+
+### **5\. API 事务一致性风险：跨表更新未强调 Transaction**
+
+* **计划现状**：任务 BE-3 设计了 PUT /.../basic-info 和 PUT /.../rvw-config。  
+* **冲突点**：在“保存并发布”时，如果前端提交了一个大表单，同时修改了主表 tenants（如：期刊名称）和关联表 tenant\_rvw\_configs（如：方法学 Prompt）。若分开调用接口或在 Service 层不使用事务，极易造成数据不一致。  
+* **修正建议**：  
+  在 BE-3 任务描述中增加硬性约束：**涉及跨 tenants 与 tenant\_rvw\_configs 表的同时写入操作，必须使用 Prisma $transaction 包裹，确保原子性。**
+
+## **🟢 低风险项 (P2级 \- 细节补齐)**
+
+### **6\. OTHER 语言的枚举映射与回退机制**
+
+* **计划现状**：计划 3.2 提到“英文/其他 \-\> en”。  
+* **建议补充**：在后端 SkillExecutor 的合并逻辑中（BE-4），明确将这一点写进代码注释：  
+  // 当 journalLanguage 为 OTHER 时，强制 fallback 到 EN 基线，以通用 SCI 标准兜底  
+  const langBase \= tenantConfig.editorialBaseStandard ??   
+                   (tenant.journalLanguage \=== 'ZH' ? 'zh' : 'en');
+
+## **🚀 最终行动建议 (Next Steps)**
+
+请开发团队在实施前对计划文档作如下微调：
+
+1. **推进独立前端**：落实 FE-1 和 FE-2，确保期刊业务拥有纯净的管理体验。  
+2. **底层数据扩充**：在 Prisma Schema 中补齐 tenant\_type 枚举，并为 journal\_language 设定 @default 兜底（或允许为空）以解决数据迁移报错风险。  
+3. **安全防线**：务必补上前端的 **“Handlebars 实时预览”** 按钮和后端的 **$transaction 事务一致性** 约束。
+
+完成以上 3 点修正后，该 MVP 计划可立即进入研发阶段。