docs: clarify new service relationships with current backend

Per user feedback, the relationships of the 4 new services to the existing backend are different than previously described:

- admin: SHARES database with current system (direct DB connection, not API). Access control via DB account/RBAC.
- review: CALLED BY current backend (gateway/assetservice invokes its API for submission; result returns via callback/message/shared table)
- ai-image-gen: CALLED BY current backend (gateway originally called MiniMax directly, now calls ai-image-gen's API)
- ai-chat: CALLED BY current backend/frontend (extracted from aichatservice)

Section 1.3 rewritten to make this distinction explicit.
Section 11.4.3 expanded to describe the different cross-namespace patterns:
  - admin: no API calls, connects to same RDS via ExternalName
  - review: needs cross-ns Dubbo to read content from each group
  - ai-image-gen / ai-chat: receive calls, may indirectly call userservice via short DNS

This also has implications for the data-layer multi-tenancy in §11.4.4 — admin still needs group_id to filter across groups when reading the shared DB.

docs/superpowers/specs/2026-06-08-docker-to-k8s-migration-design.md

@@ -61,16 +61,20 @@ TopFans 是一个"明星粉丝平台"。不同明星的粉丝量差异极大:
 
 ### 1.3 即将到来的新服务
 
-代码或 PRD 中已提及、未来需要独立部署的**全新系统**(非复用现有服务,各自独立代码库、独立 DB,只通过 API 互相调用):
+代码或 PRD 中已提及、未来需要独立部署的**新服务**。**与现有服务的关系各不相同**,明确如下:
 
-| 服务 | 作用 | 关系 |
+| 服务 | 作用 | 与现有服务的关系 |
 |---|---|---|
-| `admin` | 后台管理平台(运营、客服) | **独立系统**,通过 API 调用 userservice / 其他服务 |
-| `review` | 审核工作流(UGC 内容审核) | **独立系统**,通过 API 调用 assetservice 读取待审内容,审核结果回写自己的 DB |
-| `ai-image-gen` | AI 图片生成(镭射卡) | **独立系统**,gateway 改为通过 API 调用它(原 MiniMax 调用逻辑迁过去) |
-| `ai-chat` | AI 对话(粉丝互动) | **独立系统**,前端通过 API 调用它(从 aichatservice 拆出来) |
+| `admin` | 后台管理平台(运营、客服) | **共享数据库**: 直接连同一个 PostgreSQL 实例(可能不同 schema,共享用户/订单/内容数据),不走 API 调用 |
+| `review` | 审核工作流(UGC 内容审核) | **被现有后端调用**: 现有后端(gateway / assetservice)调用 review 的 API 提交审核任务,review 异步审核后结果回写(可通过 callback / 消息 / 共享表) |
+| `ai-image-gen` | AI 图片生成(镭射卡) | **被现有后端调用**: gateway 原本直接调用 MiniMax,改为调用 ai-image-gen 服务的 API(原 MiniMax 调用逻辑迁过去) |
+| `ai-chat` | AI 对话(粉丝互动) | **被现有后端/前端调用**: 从 aichatservice 拆出来,前端或 gateway 调用它的 API(原 aichatservice 的能力) |
 
-> **关键澄清**: 这四个服务与现有 `userservice` / `assetservice` / `aichatservice` 等**没有代码级复用关系**,也没有共享 DB schema。它们是完全独立的新服务,通过 HTTP/gRPC API 互相调用。K8s 迁移任务只负责**为它们预留 namespace 位置和部署模板**,不涉及实现。
+> **关键澄清**:
+> - `admin` **不走 API**,通过共享 DB 直连,**权限和访问范围由 DB 账号/RBAC 控制**
+> - `review` / `ai-image-gen` / `ai-chat` 是**被调用方**,由现有后端(gateway / 前端)主动调用
+> - 这四个服务与现有 `userservice` / `assetservice` / `aichatservice` 等**没有代码级复用关系**
+> - K8s 迁移任务只负责**为它们预留 namespace 位置和部署模板**,不涉及实现
 
 ---
 
@@ -649,12 +653,21 @@ spec:
     persistentvolumeclaims: "5"
 ```
 
-#### 11.4.3 跨 namespace Dubbo 调用 (新服务 ↔ 数据服务)
+#### 11.4.3 跨 namespace 调用模式 (新服务 ↔ 数据服务)
 
-Phase 2 启动后,`admin` / `review` 部署在 `topfans-shared`,需要调用各组数据服务(如 review 审核 group-a 的 gallery):
+Phase 2 启动后,部署在 `topfans-shared` 的新服务与各组数据服务的交互方式各不相同:
+
+**`admin` (共享 DB,不走 API)**:
+- 直接连同一个 PostgreSQL,按 RBAC 权限访问数据
+- **不需要**调用数据服务 API
+- K8s 部署上:`admin` Pod 内的 `DB_HOST=postgres-ext`(同 §4.2.2 的 ExternalName),与现有服务共用同一份 RDS
+
+**`review` (被现有后端调用 + 需读数据)**:
+- 现有后端调用 review 提交审核任务(API 入站,不需要跨 ns)
+- review 审核时需要**读取各组**待审内容(如 group-a 的 gallery),需跨 ns 调数据服务
+- 跨 ns Dubbo 调用模式(可选方案):
 
 ```yaml
-# 未来 review 服务的环境变量 (在 topfans-shared namespace)
 # 方式 1: 静态全限定名(每组一个变量)
 DUBBO_GALLERY_SERVICE_URL_GROUP_A: tri://galleryservice.topfans-group-a.svc.cluster.local:20001
 DUBBO_GALLERY_SERVICE_URL_GROUP_B: tri://galleryservice.topfans-group-b.svc.cluster.local:20001
@@ -662,7 +675,11 @@ DUBBO_GALLERY_SERVICE_URL_GROUP_B: tri://galleryservice.topfans-group-b.svc.clus
 # 方式 2: 用配置中心或服务发现动态获取 (推荐)
 ```
 
-**应用层需支持 group 维度路由**。具体实现属于应用层设计,不在 K8s 范围。
+**`ai-image-gen` / `ai-chat` (被调用,无跨 ns 需求)**:
+- gateway / 前端调用它们时通过 Ingress 进 shared ns,不需要主动调数据服务
+- 可能间接调 userservice(获取用户信息),走短 DNS 名
+
+**应用层需支持 group 维度路由**(针对 review)。具体实现属于应用层设计,不在 K8s 范围。
 
 #### 11.4.4 应用层多租户改造 (数据层)