feat: chat integration, tenant admin spec, backend chat service, miniprogram updates, DEMO moved to tmp, XCX-TEST removed, migrations & docs

docs/prd/Neo_Specs/NS2-ai-prompt-refinement.md

@@ -286,15 +286,102 @@ async def build_page_text(
 - 主观信息需在 Prompt 中标注【来源：XXX，请甄别信息真实性】
 - reference 从 `ai_cache` 获取 app8 最新 + 最近 2 套历史
 
-### 3.6 应用 1：页面上下文文本化
+### 3.6 应用 1：biz_params 权限隔离（已实现，需确认）
 
-应用 1 的 `_build_page_context()` 和 `_build_source_context()` 需要根据 `source_page` 类型，调用对应的数据获取函数并格式化为文本。
+> ✅ RNS1.4 已在 `app1_chat.py` 的 `_build_system_prompt()` 中实现 biz_params 拼接。
 
-实现要点：
-- 每个页面类型对应一个文本化函数
-- 文本化输出为结构化中文描述（非 JSON），便于 AI 理解
+应用 1 通过 `biz_params.user_prompt_params` 向百炼 AI 传入用户身份信息，实现数据查询隔离：
+
+```python
+system_content = {
+    "task": "你是台球门店的 AI 助手...",
+    "biz_params": {
+        "user_prompt_params": {
+            "User_ID": str(user_id),
+            "Role": role,        # "助教" | "管理者"
+            "Nickname": nickname,
+        },
+    },
+}
+```
+
+权限控制规则（百炼平台侧执行）：
+- 助教身份：仅允许查询与该助教相关的数据，禁止查询其他助教业绩/工资/客户关系等敏感数据，禁止查询门店级财务数据
+- 管理者身份：可查询该门店下所有数据
+- 所有查询必须包含 `site_id` 过滤
+
+NS2 需确认事项：
+- 前端调用 `POST /api/chat/conversations/:id/messages` 时，是否正确传入 `user_id`/`role`/`nickname`
+- 后端从 JWT token 中提取用户信息并传入 `_build_system_prompt()`，确保不可伪造
+
+### 3.7 应用 1：页面上下文传递与文本化
+
+#### 当前问题（P5 PRD 与 RNS1.4 实现的差异）
+
+P5 PRD 原始设计：
+```
+前端跳转 chat.html 时传入 source_page + page_context + screen_content
+→ 后端接收后文本化 → 拼接为首条 user message
+```
+
+RNS1.4 当前实现：
+```
+前端跳转 chat 页面时仅传入 contextType + contextId（如 task/12345）
+→ 后端 _build_page_context() 为占位实现，page_context 和 screen_content 为空
+→ AI 无法获得页面上下文
+```
+
+#### 解决方案：后端根据 contextType 自动获取页面上下文
+
+采用方案 B（简化前端，后端自动查询），与 RNS1.4 已有的 `contextType`/`contextId` 参数兼容：
+
+```
+前端传入 contextType="task-detail" + contextId="12345"
+→ 后端 build_page_text("task-detail", 12345, site_id)
+→ 后端从数据库获取任务详情、客户信息、备注、AI 分析等
+→ 格式化为结构化中文文本
+→ 拼接为首条 user message 的 page_context 字段
+```
+
+#### contextType 映射表
+
+| 前端 contextType | 后端数据获取 | 文本化内容 |
+|-----------------|-------------|-----------|
+| `task-detail` | coach_tasks + member + notes + ai_cache | 任务信息 + 客户信息 + 备注 + AI 分析 |
+| `customer-detail` | member + consumption + clues | 客户全信息 + 消费记录 + 维客线索 |
+| `coach-detail` | assistant + tasks + notes | 助教信息 + 任务统计 + 备注 |
+| `board-finance` | finance DWS 汇总（按当前筛选条件） | 财务数据摘要 |
+| `board-customer` | 当前筛选维度 top 列表 | 客户排名摘要 |
+| `board-coach` | 当前筛选维度排名 | 助教排名摘要 |
+| `performance` | salary_calc + daily_detail | 绩效数据摘要 |
+| `my-profile` | user info + assistant binding | 个人信息摘要 |
+| `task-list` | 长按的任务摘要 + 客户-助教关系 | 任务概要 |
+| `customer-service-records` | 服务记录列表 | 服务记录摘要 |
+
+#### 前端需要补充的参数
+
+当前前端仅传 `contextType` + `contextId`，对于看板类页面需要额外传入筛选条件：
+
+| contextType | 必传参数 | 可选参数 |
+|-------------|---------|---------|
+| `task-detail` | contextId（taskId） | — |
+| `customer-detail` | contextId（memberId） | — |
+| `coach-detail` | contextId（assistantId） | — |
+| `board-finance` | — | `timeDimension`（时间维度）、`areaFilter`（区域筛选） |
+| `board-customer` | — | `dimension`（排序维度）、`typeFilter`（类型筛选） |
+| `board-coach` | — | `dimension`、`projectFilter`、`timeDimension` |
+| `performance` | — | `timeDimension` |
+| `task-list` | contextId（taskId） | — |
+| `my-profile` | — | — |
+
+#### 实现要点
+
+- 每个页面类型对应一个文本化函数，在 `data_fetchers/page_context.py` 中实现
+- 文本化输出为结构化中文描述（非 JSON），便于 AI 理解上下文
 - 数据量控制：每个页面上下文不超过 2000 字符，避免 token 浪费
 - 敏感信息脱敏：不传入 member_phone 等断档字段
+- 看板类页面：若前端未传筛选条件，使用默认值（如 board-finance 默认"本月"）
+- 错误降级：数据获取失败时，page_context 传入"页面上下文获取失败"，不阻断对话
 
 ---
 
@@ -348,12 +435,18 @@ async def build_page_text(
 
 ```
 用户点击 AI 入口
-  → 前端传入 source_page + context_data
-  → 后端 build_page_text(source_page, context_data)
-  → 拼接为首条 user message
+  → 前端传入 contextType + contextId（+ 可选筛选参数）
+  → 后端 build_page_text(contextType, contextId, site_id, filters?)
+  → 从数据库获取对应页面数据，格式化为结构化中文文本
+  → 拼接为首条 user message 的 page_context 字段
+  → 注入 biz_params（User_ID/Role/Nickname）到 system prompt
   → SSE 流式调用百炼 API
 ```
 
+> ⚠️ 与 P5 PRD 原始设计的差异：P5 设计为前端传入 `source_page` + `page_context` + `screen_content`，
+> RNS1.4 实际实现为前端传入 `contextType` + `contextId`，后端自动查询数据库获取上下文。
+> NS2 沿用 RNS1.4 方案（后端自动获取），不要求前端传入原始页面数据。
+
 ---
 
 ## 六、参考文档
@@ -361,12 +454,16 @@ async def build_page_text(
 | 文档 | 路径 | 用途 |
 |------|------|------|
 | P5 AI 集成 spec | `docs/prd/specs/P5-miniapp-ai-integration.md` | Prompt JSON 结构定义、调用链时序 |
+| AI 应用 Prompt | `docs/prd/ai-app-prompts.md` | 8 个应用的 System Prompt、biz_params 定义 |
+| AI 需求文档 | `docs/prd/AI需求2.md` | 8 个应用的详细需求表、传参格式 |
+| AI 应用→页面映射 | `docs/reports/2026-03-20__ai_app_page_mapping.md` | 各应用输出内容在哪个页面的什么位置展示 |
 | API 契约 | `docs/miniprogram-dev/API-contract.md` | 接口响应格式（决定数据结构） |
 | DWD-DOC 标杆 | `docs/reports/DWD-DOC/` | 金额口径、字段语义权威参考 |
-| AI 应用骨架代码 | `apps/backend/app/ai/apps/app*.py` | 当前骨架实现 |
+| AI 应用骨架代码 | `apps/backend/app/ai/apps/app*.py` | 当前骨架实现（含 biz_params 已实现） |
 | 百炼客户端 | `apps/backend/app/ai/bailian_client.py` | API 调用封装 |
 | 缓存服务 | `apps/backend/app/ai/cache_service.py` | ai_cache 读写 |
 | NS1 接口设计 | `docs/prd/Neo_Specs/NS1-xcx-backend-api.md` | 后端数据结构参考 |
+| RNS1.4 任务计划 | `.kiro/specs/rns1-chat-integration/tasks.md` | 当前 chat 模块实施进度 |
 
 ---
 
@@ -413,7 +510,12 @@ async def build_page_text(
 - [ ] T7：完善 `app6_note.py` 的 `build_prompt()`（备注+客户数据 → 备注分析）
 - [ ] T8：完善 `app7_customer.py` 的 `build_prompt()`（客户全量数据 → 运营策略）
 
-### Batch C：应用 1 页面文本化 + 联调
+### Batch C：应用 1 页面文本化 + 前端配合
 - [ ] T9：实现各页面类型的文本化函数（task-detail/customer-detail/board-*/performance 等）
-- [ ] T10：补充 `app1_chat.py` 的 `_build_page_context()` 调用文本化函数
-- [ ] T11：端到端联调（触发事件 → Prompt 拼接 → 百炼调用 → 缓存写入 → 前端展示）
+- [ ] T10：补充 `app1_chat.py` 的 `_build_page_context()` 调用文本化函数，根据 `contextType` 路由到对应文本化函数
+- [ ] T11：前端补充看板类页面的筛选参数传递（board-finance/board-customer/board-coach 跳转 chat 时传入当前筛选条件）
+- [ ] T12：确认 biz_params 端到端正确性（前端 JWT → 后端提取 user_id/role/nickname → system prompt 注入 → 百炼权限隔离生效）
+
+### Batch D：联调与验证
+- [ ] T13：端到端联调（触发事件 → Prompt 拼接 → 百炼调用 → 缓存写入 → 前端展示）
+- [ ] T14：应用 1 页面上下文联调（各入口页面 → contextType/contextId → 后端文本化 → AI 对话验证上下文感知）