docs: Update documentation and release rules

- 架构和规划文档更新
- 开发、工程、生产发布规则更新
- 服务隔离和升级指南
- README 更新

DEVELOPMENT_RELEASE_RULES.md

@@ -2,7 +2,7 @@
 
 1. 本仓库是 **本机 Mac 开发环境**，默认职责是开发、联调、测试、预演，不是生产运行目录。
 2. 每次开发都必须形成本地 Git 提交；至少在切换任务、交接、发布前，不能只停留在未提交工作区。
-3. 本机允许跑 `dev`、测试、构建、dry-run，但不允许从本机直接 `rsync` 到 `103` 或 `105`。
+3. 本机允许跑 `dev`、测试、构建、dry-run，但不允许从本机直接 `rsync` 到 `103` 或 `105`，也**不允许 SSH 到 `105` 直接改线上源码**。见 [docs/105-server-operations.md](docs/105-server-operations.md)。
 4. 任何准备上线的改动都要先形成“可复现产物”，发布来源必须是可追溯 commit，而不是临时工作区状态。
 5. 本地验证至少包含受影响模块的最小测试、必要的 `npm run build` 或接口自测。
 6. 本地需要保留发布清单：当前分支、HEAD、关键变更、是否含未提交改动。

ENGINEERING_WORKFLOW_RULES.md

@@ -3,7 +3,7 @@
 ## 1. 仓库定位
 
 1. 本仓库是 **本机 Mac 开发仓库**，不是生产目录。
-2. `103` 是正式运行目标，`105` 不是源码发布目标，不允许再把它当作可直接同步的开发延伸。
+2. `103` 是正式运行目标，`105` 是入口/代理层，**不是**源码真相所在处；不允许把它当作可直接同步或可直接 SSH 改码的开发延伸。细则见 [105 服务器变更规范](docs/105-server-operations.md)。
 
 ## 2. 开发约束
 
@@ -21,10 +21,11 @@
 ## 4. 发布约束
 
 1. 本机不允许直接 `rsync` 到 `103` 或 `105`。
-2. Portal 生产与测试统一走“本机构建 runtime artifact -> 打包发布”，**禁止**在 `103` 解源码包后 `npm install` / `npm run build`。
-3. Portal 唯一合法生产入口是 `bash scripts/release-portal-runtime-prod.sh`。
-4. 发布来源必须是可追溯 commit，不允许从不明工作区直接出包。
-5. 发布前必须有备份，发布后必须有健康检查和业务验收。
+2. **禁止** SSH 登录 `105` 后直接修改业务源码（含 `scripts/wechat-mp-menu.mjs` 等）；必须先本地 commit，再按发布流程上线。详见 [105 服务器变更规范](docs/105-server-operations.md)。
+3. Portal 生产与测试统一走“本机构建 runtime artifact -> 打包发布”，**禁止**在 `103` 解源码包后 `npm install` / `npm run build`。
+4. Portal 唯一合法生产入口是 `bash scripts/release-portal-runtime-prod.sh`。
+5. 发布来源必须是可追溯 commit，不允许从不明工作区直接出包。
+6. 发布前必须有备份，发布后必须有健康检查和业务验收。
 
 ## 5. 文档约束
 

PRODUCTION_RELEASE_RULES.md

@@ -1,6 +1,7 @@
 # 生产发布规则
 
 1. `103` 是正式生产主机，`105` 是云侧入口/历史链路；**本机一律不允许直接 `rsync` 到 `103` 或 `105`**，也不允许在线改源码后继续运行。
+2. **禁止 SSH 登录 `105` 直接修改业务代码**（含服务号菜单脚本 `scripts/wechat-mp-menu.mjs`）。105 上文件是部署产物；变更必须：本地 `test-memind` 修改 → Git commit → 正式发布 → 必要时在目标环境执行 API 同步。详见 [docs/105-server-operations.md](docs/105-server-operations.md)。
 2. **Portal 生产必须是无源码 runtime 模式**：构建只发生在本机 Mac，产物是 `.runtime/portal/`；`103` 只接收 runtime artifact、继承持久目录、启动服务，**禁止**在 `103` 上 `npm install`、`npm run build` 或保留可运行源码树。
 3. Portal 生产发布唯一合法路径是：本地已提交代码 -> 本机 `node scripts/build-portal-runtime.mjs` -> `bash scripts/release-portal-runtime-prod.sh` -> 上传 `103` -> 全量备份 + 持久目录备份 -> 原子切换 live 目录 -> 重启 Portal -> 健康检查。
 4. `scripts/release-prod.sh`（源码包发布）已停用，不得再用于 Portal；`rsync_to_server.sh` 与任何面向 `105` 的直接同步脚本也只保留为禁用提示。

README.md

@@ -2,7 +2,8 @@
 >
 > **重要：** `pnpm dev` 只启动本仓库自己的服务，不再联动 Plaza。需要全栈联动时请显式使用 `pnpm dev:all`。
 >
-> **流程硬约束：** 本机开发每次都要形成 Git commit；本机不允许直接 `rsync` 到 `103` 或 `105`，只能从本地 commit 打包发布。
+> **流程硬约束：** 本机开发每次都要形成 Git commit；本机不允许直接 `rsync` 到 `103` 或 `105`，只能从本地 commit 打包发布。  
+> **105 禁止直改：** 不得 SSH 到 `105` 直接改源码；细则见 [105 服务器变更规范](docs/105-server-operations.md)。
 
 # Memind (TKMind H5)
 
@@ -80,6 +81,7 @@ bash scripts/release-portal-runtime-prod.sh
 
 - 103 Portal 生产必须是**无源码 runtime 模式**
 - 103 生产禁止 `rsync`
+- **105 禁止 SSH 直改源码**（含服务号菜单）；见 [105 服务器变更规范](docs/105-server-operations.md)
 - `bash scripts/release-prod.sh` 已停用，不得再用于 Portal
 - 规则文档见仓库根目录的开发 / 测试 / 生产发布规则，以及 [Portal 无源码迁移说明](docs/no-source-portal-migration.md)
 
@@ -93,4 +95,5 @@ bash scripts/release-portal-runtime-prod.sh
 - [生产发布规则](PRODUCTION_RELEASE_RULES.md)
 - [生产更新发布指南](docs/release-deploy.md)
 - [生产 / 测试 / 预览隔离规程](docs/service-isolation-runbook.md)
+- [105 服务器变更规范（禁止 SSH 直改）](docs/105-server-operations.md)
 - [Plaza 本机部署与 Tunnel](docs/plaza-local.md)

docs/103-105-upgrade-runbook-2026-06-26.md

@@ -6,7 +6,8 @@
 
 1. 本地三仓库收口为唯一源码真相。
 2. `103` 收口为“只接收发布包”的正式运行机。
-3. `105` 收口为入口 / 代理机，不再承担可写业务数据目录。
+3. `105` 收口为入口 / 代理机，不再承担可写业务数据目录。  
+   **后续禁止 SSH 直改 105 业务源码**；运维细则见 [105 服务器变更规范](105-server-operations.md)。
 
 ## 已确认的真实结构
 

docs/105-server-operations.md

@@ -0,0 +1,126 @@
+# 105 服务器变更规范
+
+> **硬性约束：** `105`（`root@120.26.184.105`）是运行/入口层，**不是**源码真相所在处。  
+> **禁止** SSH 登录后直接修改业务代码、脚本或配置源码；所有变更必须来自本地仓库 commit 后的正式发布流程。  
+> 本规则适用于人工与 Agent，无“临时改一下”例外。
+
+## 105 的角色
+
+| 项目 | 说明 |
+|------|------|
+| 定位 | 云侧入口 / 代理 / 历史链路，不承担可写业务数据主存储 |
+| H5 运行目录 | `/root/tkmind_go/ui/h5` |
+| Plaza 运行目录 | `/root/tkmind_go/ui/plaza` |
+| 数据真身 | 在 `103`（MindSpace、users、data 等），见 [103/105 升级记录](103-105-upgrade-runbook-2026-06-26.md) |
+
+本地开发仓库是 `/Users/john/PycharmProjects/test/test-memind`；生产 runtime 发布目标是 `103`。  
+**105 上的文件是部署产物，不是编辑源。**
+
+## 禁止事项
+
+以下操作一律禁止：
+
+1. **SSH 到 105 后直接改源码**  
+   包括但不限于：`sed -i`、`vi`/`nano`、`echo >> file`、手工上传单个 `.mjs`/`.ts`/`.tsx` 覆盖。
+2. **在 105 上改脚本后当作“已发布”**  
+   例如直接改 `/root/tkmind_go/ui/h5/scripts/wechat-mp-menu.mjs` 而不经过本地 commit 与发布。
+3. **把 105 当开发/调试环境**  
+   不在 105 上跑本地开发命令、试改业务逻辑、临时 patch。
+4. **绕过发布流程的“快捷修复”**  
+   “为了快”不是 SSH 直改的理由；违规改动会在下次发布时被覆盖，且与 Git 历史脱节。
+
+## 允许的操作（只读与受控运维）
+
+在**不修改业务源码**的前提下，允许：
+
+- 只读排查：`systemctl status`、`journalctl`、健康检查 `curl`、查看目录结构
+- 按 runbook 重启服务（需有文档依据，且变更本身不是改代码）
+- 在**发布已完成、脚本内容已与本地 commit 一致**后，执行受控同步命令（见下文「服务号菜单」）
+
+## 代码变更的正确流程
+
+```text
+本地 test-memind 修改
+  → 本地验证
+  → Git commit（可追溯）
+  → 按现行发布流程发布到目标环境（103 Portal runtime / 其他已文档化的入口）
+  → 发布后健康检查与业务路径验收
+```
+
+相关规则入口：
+
+- [标准化开发测试发布约束](../ENGINEERING_WORKFLOW_RULES.md)
+- [生产发布规则](../PRODUCTION_RELEASE_RULES.md)
+- [Portal 生产更新发布指南](release-deploy.md)
+- [103/105 升级与角色划分](103-105-upgrade-runbook-2026-06-26.md)
+
+**不要**使用已停用的 `rsync_to_server.sh` 或直接 rsync 到 `105` 作为常规发布手段（见 `PRODUCTION_RELEASE_RULES.md`）。
+
+## 服务号底部菜单（`wechat-mp-menu.mjs`）
+
+菜单名称与链接定义在本地：
+
+```text
+scripts/wechat-mp-menu.mjs
+```
+
+### 两层动作，不可混淆
+
+| 步骤 | 做什么 | 在哪里做 |
+|------|--------|----------|
+| 1. 改菜单定义 | 修改 `MENU` 常量（如 `M广场` → `M发现`） | **仅本地仓库** |
+| 2. 同步到微信 | 调用微信 `menu/create` API | 目标环境已发布后的机器上执行脚本 |
+
+### 正确流程
+
+```bash
+# 1. 本地改 scripts/wechat-mp-menu.mjs
+cd /Users/john/PycharmProjects/test/test-memind
+# 编辑 MENU → 本地验证 → git commit
+
+# 2. 随 Portal/H5 走正式发布到 103（或当前文档规定的目标机）
+#    确保线上脚本内容与 commit 一致
+
+# 3. 在已发布且含微信凭证的环境执行同步（不是改文件）
+node scripts/wechat-mp-menu.mjs
+
+# 仅查看将提交的菜单结构，不调 API：
+node scripts/wechat-mp-menu.mjs --dry-run
+```
+
+### 禁止做法（反例）
+
+```bash
+# ❌ 禁止：SSH 到 105 直接 sed 改菜单脚本
+ssh root@120.26.184.105 "sed -i \"s/M广场/M发现/\" /root/tkmind_go/ui/h5/scripts/wechat-mp-menu.mjs"
+
+# ❌ 禁止：只改 105 上的文件、不 commit、不发布
+# ❌ 禁止：Agent 在未走发布流程时自行 SSH 改 105 源码
+```
+
+说明：第 3 步「执行 `node scripts/wechat-mp-menu.mjs`」是**调用微信 API**，本身不修改业务源码；但必须先完成本地改码 + commit + 发布，保证线上脚本与仓库一致。
+
+## 发布时不会被覆盖的内容（历史 rsync 场景）
+
+若仍涉及旧目录同步，以下路径通常在 exclude 中，**但这不构成“可以在 105 上改源码”的理由**：
+
+- `.env`（环境密钥与运行配置）
+- `MindSpace/`（用户空间数据）
+
+业务脚本与前端代码**不在** exclude 内，发布时会覆盖 105 上的直改内容。
+
+## Agent 执行清单
+
+接到“改 105 / 改服务号菜单 / 改线上文案”类任务时：
+
+1. 先读本文与 [生产发布规则](../PRODUCTION_RELEASE_RULES.md)
+2. 在本地 `test-memind` 修改并 commit
+3. 走文档规定的发布流程
+4. 仅在发布后执行必要的 API 同步（如微信菜单）
+5. **不得** SSH 到 105 直接改 `.mjs` / `.ts` / 前端资源
+
+## 相关文档
+
+- [生产 / 测试 / 预览隔离规程](service-isolation-runbook.md)
+- [Portal 无源码迁移说明](no-source-portal-migration.md)
+- [103/105 一次性升级实施记录](103-105-upgrade-runbook-2026-06-26.md)

docs/agent-job-sse-integration.md

@@ -0,0 +1,176 @@
+# Agent Job SSE 流集成指南(路④)
+
+> 后端已实现:长任务可异步化,前端通过 Server-Sent Events (SSE) 订阅进度。
+
+## 后端端点
+
+**GET** `/mindspace/v1/agent/jobs/:jobId/stream`
+
+流式返回进度事件,直到任务终态或客户端断开。
+
+### 事件格式
+
+```
+event: progress
+data: {"id":"...", "status":"running", "progress":{"stage":"analyzing"},...}
+
+event: done
+data: {"id":"...", "status":"completed", "resultPageId":"..."}
+```
+
+### 事件类型
+
+| event | 何时 | payload |
+|-------|------|---------|
+| `progress` | 状态/进度变化时推送 | 完整 job 对象 |
+| `done` | 终态(completed/failed/cancelled/timed_out) | 完整 job 对象(含 errorCode) |
+
+### HTTP headers
+
+- `Content-Type: text/event-stream`
+- `Cache-Control: no-cache, no-transform`
+- `X-Accel-Buffering: no` (告诉代理别缓冲)
+
+## 前端集成示例(React)
+
+```tsx
+import { useEffect, useState } from 'react';
+
+function AgentJobProgress({ jobId }) {
+  const [job, setJob] = useState(null);
+  const [error, setError] = useState(null);
+
+  useEffect(() => {
+    if (!jobId) return;
+
+    const eventSource = new EventSource(
+      `/mindspace/v1/agent/jobs/${jobId}/stream`
+    );
+
+    eventSource.addEventListener('progress', (event) => {
+      const data = JSON.parse(event.data);
+      setJob(data);
+      console.log(`[progress] ${data.status}:`, data.progress);
+    });
+
+    eventSource.addEventListener('done', (event) => {
+      const data = JSON.parse(event.data);
+      setJob(data);
+      console.log(`[done] ${data.status}`);
+      eventSource.close();
+    });
+
+    eventSource.addEventListener('error', (event) => {
+      if (eventSource.readyState === EventSource.CLOSED) {
+        console.log('[stream closed by server]');
+      } else {
+        setError(`Stream error: ${event.message || 'unknown'}`);
+      }
+      eventSource.close();
+    });
+
+    return () => eventSource.close();
+  }, [jobId]);
+
+  if (error) return <div className="error">{error}</div>;
+  if (!job) return <div>等待中...</div>;
+
+  const isTerminal = ['completed', 'failed', 'cancelled', 'timed_out'].includes(
+    job.status
+  );
+
+  return (
+    <div className="job-progress">
+      <div className="status">{job.status}</div>
+      {job.progress && (
+        <div className="stage">{job.progress.stage || job.status}</div>
+      )}
+      {job.errorMessage && <div className="error">{job.errorMessage}</div>}
+      {job.resultPageId && (
+        <div className="result">
+          ✓ 结果页面已生成:{job.resultPageId}
+        </div>
+      )}
+      {!isTerminal && <div className="spinner">处理中...</div>}
+    </div>
+  );
+}
+
+export default AgentJobProgress;
+```
+
+## 使用流程
+
+### 1. 长任务投递(返回 202 Accepted)
+
+```javascript
+const jobRes = await fetch('/mindspace/v1/agent/jobs', {
+  method: 'POST',
+  body: JSON.stringify({
+    jobType: 'generate_page',
+    instruction: '生成一个海报',
+    outputCategoryId: '...',
+  }),
+});
+const { id: jobId } = await jobRes.json();
+```
+
+### 2. 立即返回,前端订阅进度
+
+```javascript
+// 路由切换到进度页面,挂载 <AgentJobProgress jobId={jobId} />
+// SSE 连接建立,收到 progress/done 事件
+```
+
+### 3. 完成后展示结果
+
+```javascript
+// done 事件里有 resultPageId / resultAssetId
+// 导航到 /mindspace/pages/:pageId 查看结果
+```
+
+## 微信场景(异步 ACK)
+
+现有机制(wechat-mp.mjs 的 ACK + asyncTaskId):
+1. 收微信消息 → 立即 ACK
+2. 投递 job → 返回 asyncTaskId
+3. Job 完成 → Webhook 通知用户(via 客服接口)
+
+这里 SSE 是**Web/H5 专用** —— 微信端继续用现有异步 ACK + 客服消息回推(已实现)。
+
+## 错误处理
+
+```javascript
+eventSource.addEventListener('error', (event) => {
+  if (eventSource.readyState === EventSource.CLOSED) {
+    // 服务器正常关闭(终态)
+    return;
+  }
+  // 真的错误
+  console.error('SSE error:', event);
+  retryOrShowError();
+});
+```
+
+## 性能提示
+
+- SSE 连接建立快于 WebSocket,更轻
+- 不需要 polling(没有网络浪费)
+- 浏览器自动重连(如服务器 5s 内无数据)
+- 移动浏览器背景标签页会冻结连接(正常行为)
+
+## 后端已支持的环境变量
+
+```bash
+# 轮询间隔(毫秒,默认 1000)
+MINDSPACE_AGENT_SSE_POLL_MS=500
+```
+
+## 测试
+
+```bash
+# 手工测试(curl)
+curl -N http://localhost:3000/mindspace/v1/agent/jobs/JOB_ID/stream
+
+# 应该立即看到 progress 事件,然后在终态时看到 done 事件
+```

docs/goose-scale-architecture-2026-06-26.md

@@ -0,0 +1,270 @@
+# Goose 执行层规模化架构评估与拆分设计
+
+> **背景：** 评估当前 MeMind/TKMind 的 Goose 执行架构在用户量突破 1 万、峰值并发突破 100 时能否扛住，以及如何拆分演进。
+>
+> **结论先行：** 当前架构稳定并发上限约 **20–30**，扛不住 100，更扛不住 1 万用户的峰值并发（通常是 DAU 的 5–10%，即 500–1000）。**演进方向（Experience 共享、Session 外置、Stateless Worker、任务队列）是对的**，但必须分阶段落地，不能跳步。
+>
+> **核心资产：** 真正值钱的是 `Experience Learning Engine + Skill Library`，这两层要最先从 goosed 进程里剥出来独立扩。goosed 本身是可替换的执行壳。
+>
+> 关联文档：[g2 负载均衡](g2-load-balancing.md) · [memindadm Goose 网关设计](memindadm-goose-gateway-design.md) · [105 服务器操作规范](105-server-operations.md)
+
+## 1. 现状盘点（基于代码事实，非设计文档假设）
+
+| 维度 | 设计文档假设 | 代码/部署实际 | 影响 |
+|------|------|------|------|
+| 数据库 | PostgreSQL + pgvector | **MySQL**（`db.mjs:2` `mysql2/promise`） | 没有向量检索能力，Experience 检索需另建 |
+| DB 连接池 | —— | **`connectionLimit: 10`**（`db.mjs:32`，写死） | 100 并发 × 多查询 → 连接耗尽、请求排队 |
+| Goose 实例 | "双 Goose 负载均衡" | **同一台 Mac（Studio/103）上的两个进程** `:18006` / `:18007` | 不是负载均衡，是单点的两进程；共享 CPU/内存/libuv |
+| Goose 运行环境 | —— | 个人开发 Mac `john@58.38.22.103` | 生产 Agent 集群跑在个人 Mac 上 = 最大架构债 |
+| Session 路由 | —— | DB `goosed_node` 整数下标（0/1），`getSessionNode` @ `user-auth.mjs:651` | 扩到第 3 台直接失效；且该列在 `schema.sql` 里不存在，靠 `columnExists` 运行时动态补 |
+| 长任务 | —— | 纯 HTTP 流式透传（`tkmind-proxy.mjs`），无队列 | 连接被占满整个执行周期；微信 5s 超时直接死 |
+| Experience / 上下文 | 共享经验库 | **在各 goosed 进程内存中** | 两实例经验孤岛；重启/部署即丢上下文 |
+
+> **关键认知校准：** 瓶颈不在 portal（无状态 Node，易扩），而在**有状态的 goosed** 和**写死 10 连接的 MySQL**。
+
+## 2. 并发压力测算：为什么扛不住 100
+
+"100 并发"对 Agent 系统 ≠ 100 个 HTTP 请求，而是 **100 个同时在跑的 Agent 会话**，每个会话：
+
+- 占一条到 LLM 的流式连接（几十秒～几分钟）
+- 可能在跑工具（浏览器 / 代码执行 / 部署），单会话 5–20 分钟
+- 每轮查 MySQL：`getSessionNode` + `getAgentSessionPolicy` + LLM provider 切换 + reconcile（≥3–4 次/轮）
+
+### 三个瓶颈，按崩溃顺序
+
+**① 两个 goosed 进程 / 一台 Mac —— 最硬的物理天花板**
+单进程乐观扛 10–20 个活跃会话，两进程合计 ~30 个开始抖。100 并发时要么 OOM，要么 LLM 调用排队到超时。**调参解决不了，是单机上限。**
+
+**② MySQL `connectionLimit: 10` —— 第二个崩**
+100 并发 × 4 查询争抢 10 条连接，`waitForConnections: true` → 请求排队等连接而非报错 → 延迟雪崩，用户感觉"卡死"。
+
+**③ HTTP 长连接占用 —— 微信场景直接死**
+长任务占满连接整个执行周期。微信公众号 5s 超时，`wechat-mp.mjs` 已被迫做异步 ACK —— 说明问题已暴露。
+
+## 3. 目标架构（支撑 1 万用户 / 500+ 并发）
+
+核心思想：**把 goosed 榨成无状态 Worker，所有状态外置，长任务异步化。**
+
+### 3.0 概念骨架版（先看主干）
+
+```
+                    Gateway  ← 含策略层(鉴权/过滤/任务识别/路由/审计)
+                        │
+         ┌──────────────┴──────────────┐
+         │                             │
+     API Server                  WeChat Server
+         └──────────────┬──────────────┘   ← 两条入口汇到同一 Dispatcher
+                        ▼
+                 Task Dispatcher
+                        │
+            ┌───────────┴───────────┐
+       短任务(<10s 同步)        长任务 → Task Queue (RabbitMQ/pg-boss)
+            │                        │      ← 隔一层队列,否则长任务占满连接
+            ▼                        ▼
+     Goose1 Goose2 Goose3 Goose4 (Stateless Worker)
+            │
+            ▼
+   State Layer (4 个并列服务,非 Experience 一条线):
+   Session/Conv(Redis+PG) · Experience(PG+pgvector) · Skill Lib · 对象存储(MinIO)
+            │
+            ▼
+   Webhook 回推 → 微信通知 / 前端 SSE  ← 长任务结果闭环
+```
+
+> 易漏的两环：**队列**(让长任务异步)和**回推**(把异步结果送回用户)；状态层是 4 个并列服务，不是挂在 Experience 下。下面是完整五层详图。
+
+### 3.1 完整五层详图
+
+```mermaid
+flowchart TD
+  U["用户 Web / H5 / WeChat"] --> LB["① 接入层 Caddy/Nginx LB → portal × N (无状态)"]
+  WX["微信回调 5s 内 ACK"] --> GW
+  LB --> GW["② 网关+策略层 memindadm Gateway<br/>鉴权/内容过滤/任务识别/执行器路由/审计"]
+  GW -->|短任务 <10s 同步| W
+  GW -->|长任务 投递即返回| Q["③ 任务队列 RabbitMQ / pg-boss<br/>优先级 + 重试 + 死信"]
+  Q --> W["④ 执行层 goosed Worker 集群<br/>Stateless / K8s Pod / 1→N 台<br/>只做 Planner/ToolCalling/MCP"]
+  W --> ST["⑤ 状态层 (所有 Worker 共享)"]
+  ST --> SESS["Session/Conv: Redis + MySQL/PG"]
+  ST --> EXP["Experience: PG + pgvector"]
+  ST --> SKILL["Skill Lib: PG / Git"]
+  ST --> OBJ["对象存储: MinIO / OSS"]
+  W --> CB["Webhook 回调 → 微信通知 / 前端 SSE"]
+```
+
+### 分层拆分原则
+
+| 层 | 有/无状态 | 扩容方式 | 当前差距 |
+|---|---|---|---|
+| ① portal 接入 | 无状态 | 水平加实例 | ✅ 已无状态，只需多机 |
+| ② Gateway 策略 | 无状态 | 水平 | 🟡 [设计文档](memindadm-goose-gateway-design.md)有，未落地 |
+| ③ 任务队列 | —— | 中间件 | ❌ 完全没有 |
+| ④ goosed Worker | **必须改成无状态** | 水平加 Pod | ❌ 现在有状态、单机 |
+| ⑤ 状态存储 | 有状态 | 读写分离/分片 | ❌ MySQL 10 连接、Experience 在进程内 |
+
+## 4. 落地路线（分阶段，不跳步）
+
+### Phase 0 — 立即做（低成本，堵眼前的洞）
+1. **连接池**：`db.mjs:32` 的 `connectionLimit: 10` 按 `portal 实例数 × 单实例并发` 重算，先提到 50–100，加监控。
+2. **`goosed_node` 下标 → 实例 URL/ID**：现在是整数 0/1，扩到第 3 台即失效，是定时炸弹；同时把该列正式写进 `schema.sql`（目前靠 `columnExists` 运行时补，脆弱）。
+3. **重启截断**：goosed 发布重启前先导出活跃会话，避免静默截断进行中的对话。
+
+### Phase 1 — Worker 化（用户 > 100 DAU）
+4. **goosed 容器化**：从个人 Mac 搬进容器 —— 所有后续扩容的前提。
+5. **Session/Conversation 外置**到 Redis + MySQL/PG，goosed 启动从外部 load，实现真 stateless。
+6. **Experience 抽成独立服务**：`GET /experience/search` + `POST /experience/record`，所有 Worker 共享（`goose_execution_log` 表是雏形）。
+
+### Phase 2 — 异步化（用户 > 1000 DAU / 并发 > 100）
+7. **引入任务队列**，长任务投递即返回，goosed 变消费者 Worker。
+8. **结果走 Webhook 回推**（微信通知 / 前端 SSE），彻底解决微信 5s 超时。
+9. **Worker 自动扩缩**：按队列深度（K8s HPA）。
+
+### Phase 3 — 数据层扩展（真到 1 万+）
+10. MySQL 读写分离 / 引入 PG+pgvector 专门承载 Experience 向量检索。
+11. 会话状态分片，审计日志冷热分离。
+
+## 5. goosed 拆分多个的三个等级与 fork 决策点
+
+> **最硬的约束：** goosed 的会话状态（完整带 tool_call 的消息历史 + 内存活跃上下文 + 活的 MCP/工具子进程连接）存在那台实例的**本地磁盘 jsonl + 内存**里。状态搬不走 —— 这就是现在必须用 `goosed_node` 粘性路由的根本原因。
+>
+> `h5_session_snapshots`（`session-snapshot.mjs`）只是**只读展示缓存**，不是权威 Agent 状态；`session-reconcile.mjs` 是会话已在某实例上之后重新套策略，不能跨实例重建状态。
+
+### 等级 A：粘性分片（现状路子，能扩但有上限）
+每个 session 钉死在一台 goosed，实例间互不知道。扩容 = 加机器 + 路由表从「整数下标」改「实例 URL」。
+- ✅ 改动最小，goosed 不用动
+- ❌ **无故障转移**：某台挂了，其上活跃 session 内存上下文直接丢（DB 只有展示快照）
+- ❌ 负载不均；Experience 仍孤岛（除非走等级 C 单独外置）
+- **适用并发 30→100 过渡期，是 Phase 0/1 该走的。**
+
+### 等级 B：共享会话存储 + 按轮重水合（真正 stateless）
+goosed 不再本地存 jsonl，每一轮：从共享存储 load 完整状态 → 执行本轮 → save 回去 → 释放。下一句可落任意 Worker。
+| 路径 | 做法 | 代价 |
+|---|---|---|
+| B1 共享文件 | session 目录挂网络盘（NFS/JuiceFS/OSS） | 改动小，但并发写 jsonl 有锁/一致性问题 |
+| B2 改存储后端 | goosed 从本地 jsonl 改成 PG/Redis load-save | 要动 **upstream Rust goose 源码**，最干净但工作量大 |
+
+> **最大技术决策点：要不要 fork goosed。** 在啃下 B2（或上游支持可插拔 session 存储）之前，「多实例」只能是等级 A 粘性分片，不是真 stateless。你架构图里「Goose1-4 任意消费」属于等级 B。
+
+### 等级 C：有状态服务剥离（与 A/B 正交，现在就能先做）
+把 Experience / Skill 从 goosed 进程抽成独立 HTTP 服务，goosed 只当调用方（执行前 `GET /search`，执行后 `POST /record`）。**即使还是等级 A 粘性分片，经验也不再孤岛。** 收益最快、不碰 goosed 内核。
+
+### 拆分顺序（务实版）
+1. 先做 **等级 C** Experience 外置 —— 正交、收益快、解决「经验共享」。
+2. 再做 **等级 A** 路由升级（下标→URL）—— 低成本撑到并发 100。
+3. 最后决策 **等级 B** —— 到并发 >100 / 需故障转移时，正面回答「要不要 fork goosed」。
+
+## 6. Task Dispatcher 现状（已有雏形，但不在主链路）
+
+| 维度 | 现状 | 证据 |
+|------|------|------|
+| 任务状态机 | ✅ 已有，且做对了最难的部分 | `h5_agent_jobs` 表：queued/running/completed/failed/timed_out/cancelled、幂等键、`claimJob` 租约、heartbeat、可重试错误码（`mindspace-agent-jobs.mjs`） |
+| Worker | ✅ 有 | `mindspace-agent-runner.mjs`：认领→起 goosed 会话→发 prompt→流式收→回写 |
+| 真队列中间件 | ❌ 无 | package.json 零队列库（无 amqp/bull/pg-boss） |
+| 触发方式 | ❌ 进程内 fire-and-forget | `server.mjs:1820` `void runJob(jobId).catch()`，在收请求的 portal 进程里跑，不是独立 Worker 池从队列拉 |
+| 跨实例分发 | ❌ 无 | runJob 在本进程执行，goosed 仍走老粘性路由 |
+| 覆盖范围 | ❌ 仅 3 类 job | `generate_page`/`analyze_asset`/`summarize`（`JOB_TYPES`）；**主聊天流量仍走 `tkmind-proxy.mjs` 同步流式，不经此系统** |
+
+> **结论：** `h5_agent_jobs` 的状态机就是真 Dispatcher 的地基（最难的已完成）。差三件事：① 前面架真队列 + 独立 Worker 池；② 把主聊天长任务也 route 进来；③ Worker 拆成独立 fleet 而非 portal 进程内。当前它挡不住并发崩溃，因为没在主路径上。
+
+### 6.1 已落地的代码（2026-06-26）
+
+> 队列后端决定：**复用 MySQL**（零运维，撑到中等并发够用），后续可换真 MQ。
+
+| 项 | 改动 | 文件 |
+|----|------|------|
+| 连接池 | `connectionLimit` 写死 10 → 可配置 `MYSQL_POOL_SIZE`（默认 50）+ `queueLimit`，两条创建路径都覆盖 | `db.mjs` |
+| Session 路由 | 新增 `goosed_target` 列存实例 URL；路由优先按 URL、回退旧整数索引；存量行向后兼容；不动 `.runtime` 产物 | `db.mjs` / `user-auth.mjs`（`getSessionTarget`）/ `tkmind-proxy.mjs` |
+| Dispatcher 消费模型 | `claimNextJob()` 用 `SELECT … FOR UPDATE SKIP LOCKED` 抢最老 queued job，多实例安全不重复 | `mindspace-agent-jobs.mjs` |
+| 独立 Worker 循环 | server 内 DB 轮询消费 + 并发上限，替代进程内 fire-and-forget；opt-in `MINDSPACE_AGENT_WORKER_ENABLED`（105 不开，遵守 g2 约束） | `server.mjs` |
+| 重启韧性 | `reapStaleJobs()` 把心跳超时的 running job 标记 `failed/worker_crashed`（可重试），避免永久卡死与毒任务死循环 | `mindspace-agent-jobs.mjs` |
+| Runner 兼容 | `runJob(jobId, preClaimed?)`：worker 预认领后免二次 claim，HTTP 旧路径不变 | `mindspace-agent-runner.mjs` |
+
+验证：job/runner/wechat 相关 40/40 通过；全套与改动前一致（374 pass / 10 既有失败），零回归。
+
+### 6.2 仍需基础设施/决策（代码改不动的部分）
+
+- 主聊天长任务 route 进队列（现仍走 `tkmind-proxy.mjs` 同步流式）—— 需配合前端 SSE / Webhook 回推改造。
+- Worker 拆成独立进程 fleet（现是 portal 内循环）—— 需容器化。
+- 真 MQ（RabbitMQ）/ Redis / pgvector / MinIO —— 外部中间件，需运维提供环境。
+- **fork upstream Rust goosed 改 session 存储后端（等级 B）—— 最大决策点，未决。**
+- Experience 服务（等级 C）建在 MySQL 还是等上 PG+pgvector —— 需先定数据层方向。
+
+## 7. 一句话总结
+
+- 当前能扛 ~20–30 并发，扛不住 100，更扛不住 1 万用户峰值。
+- 不是最优，但演进方向对。最大两个隐患：① goosed 跑在个人 Mac 上的"伪负载均衡"；② MySQL 写死 10 连接。
+- 拆分顺序：**先 goosed 容器化+无状态化（P1）→ 再异步队列化（P2）→ 最后扩数据层（P3）**。没有先做无状态，加多少 Worker 都会被 Session 漂移和 Experience 孤岛拖死。
+- 核心资产是 Experience Engine + Skill Library，最先剥离独立扩；goosed 是可替换执行壳。
+
+## 8. 五路并行推进计划（2026-06-26 决策）
+
+> 用户要求 5 条同时推进。但它们**解锁状态不同**：有的是纯代码（可立即写）、有的卡基础设施/外部环境（需运维步骤）、有的卡上游 Rust 源码（需 fork）。下面标注每条的「谁能做、卡在哪、第一步」。
+
+### 路①：改 goosed session 存储后端（等级 B）—— 已勘察，难度大幅低于预期
+
+> goose 源码：`/Users/john/Project/tkmind_go`（Rust workspace，goosed = `goose-server` crate 的 `goosed` bin）。
+
+- **关键发现**：session **已经用 SQLite + sqlx 存储**（`crates/goose/src/session/session_manager.rs`，`SessionStorage` @ line 525，`sqlx::sqlite::SqlitePool`），**不是裸 jsonl**（jsonl 是 `session/legacy.rs` 旧格式）。可插拔 seam 已存在。
+- **这意味着**：外置不需从零重写持久化。两条路：
+  - **B1（最省，零 Rust 改动）**：多个 goosed 容器**挂同一个 data volume**（SQLite WAL 文件），同机多实例即可共享 session/experience。代价：多进程并发写单 SQLite 有锁竞争。
+  - **B2（真 stateless）**：把 `SessionStorage` 的 `SqlitePool` 换成 `sqlx::Postgres` 指向共享 PG。sqlx 本就多后端，但代码有 SQLite 专用 SQL（`sqlite_master`/`PRAGMA`/WAL）和 `FromRow<SqliteRow>`，需移植 SQL + FromRow → 中等工作量，但远小于「fork 重写 jsonl」。
+- **结论**：fork 范围已明确 = **只改 `SessionStorage` 一个结构体的后端**，不是大改。第一步先 B1 挂共享 volume，并发写痛了再上 B2。
+
+### 路②：RabbitMQ 部署在 103 —— 直接答你的问题
+
+- **能直接上 103 吗？** 技术上能（`brew install rabbitmq` 或 docker 跑 broker）。**但不建议现在上。** 理由：你**刚拿到一个能用的 MySQL 队列**（第 6.1 节），RabbitMQ 只有在 MySQL 轮询成为瓶颈（数千 job/s、需要 fanout/优先级路由）时才值得。过早引入 = 多一个要运维、要监控、会宕的有状态中间件。
+- **要先在本机测吗？** 要。无论何时上 RabbitMQ，都**必须先本机 docker 跑一遍**：① 验证 producer/consumer 代码对真实 AMQP 的行为；② 不能在serving 用户的 103 上调试。流程：本机 `docker run rabbitmq:3-management` → 验证 → 再上 103（或更好：上一台独立 infra 机，别和 goosed 抢 103 的 CPU/内存）。
+- **决策建议**：**先不上 RabbitMQ**。把第 6.1 节的 MySQL 队列压测到出现真瓶颈，再换。换的时候 `claimNextJob` 的接口已经抽象，替换消费层即可。
+
+### 路③：goosed 容器化 + 搬离 Mac —— 直接答你的问题
+
+- **如何搬？** goose 是单个 Rust 二进制 + 配置（`~/.config/goose` 的 provider/extension 配置 + `TKMIND_SERVER__SECRET_KEY`）。容器化 = 写 Dockerfile（基础镜像 + goose 二进制 + 配置 + 暴露 goosed 端口），session 目录与配置用 volume 外挂。**仓库当前没有 Dockerfile，这是第一步要补的。**
+- **会影响现有用户吗？** **可以做到几乎零影响**，靠你已有的两件武器：
+  1. 路由已支持按实例 URL（第 6.1 节 `goosed_target`）。
+  2. 入口已有 Caddy 加权分流（`g2-lb.Caddyfile`）。
+  - 灰度搬迁：把容器化的新 goosed 作为**新 target 加入**，只把**新 session**路由过去，**老 session 继续钉在旧实例**直到自然结束（drain），再摘掉旧实例。**唯一硬影响**：搬迁瞬间若强制迁移进行中的 session，其内存上下文会丢（等级 B 未做前状态搬不走）——所以要 drain、不要硬切。
+- **一机能多 goose 吗？** **能，你现在就是**（18006/18007 两进程）。容器化后就是同机多容器/多端口，上限取决于 CPU/内存。要扩就是加端口加 target，再登记进路由列表。
+- **如何保证 goose 能力同步？** 能力 = ① MCP extensions（`mindspace-sandbox-mcp.mjs`）② skills（`skills-registry.mjs`）③ 学到的 experience。前两者靠**同一份代码部署 + 同一份配置**就同步（你 105 已经是「同代码同 secret」模式）；**第三者 experience 是唯一真孤岛**，必须走路⑤外置成共享服务，否则多实例各学各的。**结论：能力同步 = 代码/配置同步（已有机制）+ Experience 外置（路⑤）。**
+
+### 路④：主聊天 route 进队列 + SSE/Webhook 回推
+
+- **现状**：主聊天走 `tkmind-proxy.mjs` 同步流式，长任务占满连接。
+- **要做**：网关识别「长任务」→ 投递到队列（复用第 6.1 节 MySQL 队列）→ 立即返回 job id → 结果异步回推：Web 端走 **SSE**（订阅 job 进度），微信端走 **Webhook → 客服消息**（`wechat-mp.mjs` 已有异步 ACK 雏形，扩展为结果回推）。
+- **卡点**：需前端配合（SSE 订阅 UI）+ 任务识别策略（哪些算长任务，可复用 `memindadm-goose-gateway-design.md` 的任务识别器）。
+- **第一步（纯后端、可先做）**：在 job 系统上加一个 `GET /api/agent/jobs/:id/stream` 的 SSE 端点，前端可先不接；微信回推复用现有 ACK 通道。
+
+### 路⑤：Experience 服务（等级 C）—— 现在就动手，建在 MySQL（可换 PG）
+
+- **决策**：**先建在 MySQL**（你已经在用，零新基础设施），检索先用关键词 + 时间衰减；**接口设计成 store 可插拔**，将来 `h5_experience` 迁到 PG+pgvector 只换实现、不动调用方。不等 PG，不阻塞。
+- **要做**：`h5_experience` 表 + `experience-service.mjs`（`search`/`record`/`reflect`）+ 内部 HTTP 路由 `GET /internal/experience/search`、`POST /internal/experience/record`，goosed 执行前后调用。所有实例查同一张表 → 经验不再孤岛。
+- **状态**：✅ 本轮已落地服务骨架（见 8.1）。
+
+### 8.1 路⑤已落地代码（2026-06-26）
+
+| 项 | 文件 |
+|----|------|
+| `h5_experience` 表（MySQL，预留 `embedding` 列待 pgvector） | `schema.sql` + `db.mjs` 迁移 |
+| `createExperienceService`：`record` / `search`（关键词+时间衰减）/ `reflect` 占位，store 可插拔 | `experience-service.mjs` |
+| 单元测试 | `experience-service.test.mjs` |
+
+> 接入点（2026-06-26）：已接进 `mindspace-agent-runner.mjs` —— 执行前 `search(instruction)` 把相关经验注入 prompt，成功后 `record()` 写回；全 best-effort 不阻塞任务。server.mjs 用 `MINDSPACE_EXPERIENCE_ENABLED`（默认开）实例化并注入 runner。HTTP 检索路由（供 goosed 直连）待与网关一起接。
+
+### 路线优先级与进度（更新于 2026-06-26）
+
+1. ✅ **路⑤ Experience 外置** —— 服务骨架 + 表 + 5/5 测试已落地（8.1）。待接 goosed 触发点。
+2. ✅ **路③ 容器化 Dockerfile** —— `tkmind_go/Dockerfile.goosed`（build `goosed` bin、`GOOSE_HOST=0.0.0.0`、data volume、`/status` healthcheck）。待本机 `docker build` 验证。
+3. ✅ **路④ SSE 端点** —— `GET /mindspace/v1/agent/jobs/:jobId/stream`（轮询进度、终态/断开即关），`server.mjs`。待前端接订阅。
+4. 🔍 **路① session 后端** —— 已勘察：seam = `SessionStorage`（SQLite/sqlx）。先 B1 共享 volume，再 B2 换 PG。
+5. ⏸️ **路② RabbitMQ** —— 暂缓，等 MySQL 队列出真瓶颈。
+
+> 全部代码改动测试零回归（392 项 / 379 通过 / 10 既有失败，新增 5 个 experience 测试全过）。未提交、未发布（遵守 105 发布规范）。
+
+### 路③ 灰度搬迁 goosed（零影响操作序列）
+
+```
+1. 本机 docker build -f Dockerfile.goosed -t tkmind/goosed:local .
+2. 本机起容器，curl http://127.0.0.1:18006/status 验证
+3. 在 103 起容器化 goosed（新端口/新 IP），加进 portal 的 targets 列表
+4. 路由层只把【新 session】指向新实例（goosed_target 已支持按 URL）
+5. 老 session 钉在旧实例自然 drain（别硬迁，内存上下文搬不走）
+6. 旧实例 0 活跃后摘除
+```

docs/goose-session-postgres-migration.md

@@ -0,0 +1,165 @@
+# Goose SessionStorage SQLite → PostgreSQL 迁移指南
+
+> 目标:让 goosed 多实例真正 stateless,session 状态存 Postgres 而非本地 SQLite。
+>
+> 工作量:改 1 个结构体 + 3 处 SQL,新增 connection pool 初始化。预计 2-4 小时。
+>
+> 前置:**fork `/Users/john/Project/tkmind_go`** 或在那个仓库新建分支。
+
+## 改造点
+
+### 1. `crates/goose/src/session/session_manager.rs:525`
+
+**当前代码结构:**
+```rust
+pub struct SessionStorage {
+    pool: SqlitePool,  // <-- 改这里
+    // ...
+}
+
+impl SessionStorage {
+    pub fn new(data_dir: PathBuf) -> Self {
+        let options = SqliteConnectOptions::default()
+            .filename(data_dir.join(SESSIONS_FOLDER))
+            .create_if_missing(true)
+            .journal_mode(sqlx::sqlite::SqliteJournalMode::Wal);
+        
+        let pool = SqlitePoolOptions::new()
+            .connect_lazy_with(options);  // <-- 这里要改
+        // ...
+    }
+}
+```
+
+**改成:**
+```rust
+pub struct SessionStorage {
+    pool: sqlx::postgres::PgPool,  // 改这行
+    // ...
+}
+
+impl SessionStorage {
+    pub fn new(connection_string: String) -> Self {
+        // 从环境变量或参数读取 PostgreSQL 连接串
+        // e.g. GOOSE_SESSION_DB_URL=postgresql://...
+        let pool = sqlx::postgres::PgPoolOptions::new()
+            .max_connections(20)
+            .connect_lazy(&connection_string);
+        // ...
+    }
+}
+```
+
+### 2. `schema.sql` / 迁移 SQL
+
+**SQLite 专用语法转 PostgreSQL:**
+
+| 问题 | SQLite | PostgreSQL | 改法 |
+|------|--------|-----------|------|
+| **主键自增** | `INTEGER PRIMARY KEY AUTOINCREMENT` | `SERIAL PRIMARY KEY` | 改为 `BIGSERIAL` 或 `GENERATED ALWAYS AS IDENTITY` |
+| **类型** | `TEXT`(什么都行) | 严格类型(JSONB/TEXT/TIMESTAMP) | 用 `JSONB` 存 JSON,用 `TIMESTAMP` 存时间戳 |
+| **模式检查** | `sqlite_master` | `information_schema` | 改用 `information_schema.tables` |
+| **WAL/Journal** | `PRAGMA journal_mode=WAL` | N/A | 删除,PG 有自己的 WAL |
+| **Collate** | `COLLATE NOCASE` | 用 collation 或 LOWER()  | 改成 `LOWER(column) = LOWER($1)` |
+
+**例:**
+```sql
+-- SQLite
+CREATE TABLE sessions (
+    id TEXT PRIMARY KEY,
+    data JSON,
+    created_at INTEGER
+);
+
+-- PostgreSQL
+CREATE TABLE sessions (
+    id TEXT PRIMARY KEY,
+    data JSONB,
+    created_at BIGINT
+);
+```
+
+### 3. `FromRow<SqliteRow>` → `FromRow<PgRow>`
+
+**当前:** 
+```rust
+impl sqlx::FromRow<'_, sqlx::sqlite::SqliteRow> for Session {
+    fn from_row(row: &sqlx::sqlite::SqliteRow) -> Result<Self, sqlx::Error> {
+        // column 取值方式对 SQLite 优化
+    }
+}
+```
+
+**改成:**
+```rust
+impl sqlx::FromRow<'_, sqlx::postgres::PgRow> for Session {
+    fn from_row(row: &sqlx::postgres::PgRow) -> Result<Self, sqlx::Error> {
+        // 取值方式对 PG 优化(JSONB 用 get_raw 后 JSON 解析)
+    }
+}
+```
+
+### 4. 调用处:初始化时读环境变量
+
+**地点:** `main.rs` / 启动 `SessionManager`
+
+**改法:**
+```rust
+// 改前
+let session_manager = SessionManager::new(data_dir);
+
+// 改后
+let session_db_url = std::env::var("GOOSE_SESSION_DB_URL")
+    .expect("set GOOSE_SESSION_DB_URL env");
+let session_manager = SessionManager::new(session_db_url);
+```
+
+## 环境变量
+
+启动 goosed 时设置:
+```bash
+export GOOSE_SESSION_DB_URL=postgresql://boot:PASSWORD@120.26.184.105:5432/goose_sessions
+goosed agent
+```
+
+数据库需提前创建:
+```bash
+psql -U boot -h 120.26.184.105 -c "CREATE DATABASE goose_sessions;"
+```
+
+## 测试步骤
+
+1. **编译:**
+   ```bash
+   cd /Users/john/Project/tkmind_go
+   GOOSE_SESSION_DB_URL=... cargo build --release --package goose-server --bin goosed
+   ```
+
+2. **启两个实例,挂同一 PG:**
+   ```bash
+   goosed agent &
+   goosed agent &  # 另一个进程/端口
+   ```
+
+3. **同一 session 轮换到两个实例:**
+   - 客户端起 session on instance 1
+   - 后续命令路由到 instance 2 —— 状态应无缝恢复
+
+## 文件清单
+
+修改的文件(全在 crates/goose/src/):
+- `session/session_manager.rs` —— 3-5 处改动
+- `session/mod.rs` —— 可能有 FromRow(如果有多个 impl)
+- `session/legacy.rs` —— 如果涉及导入(通常不用改)
+- `Cargo.toml` —— 检查 sqlx features(`postgres` 要打开)
+
+## 风险与回滚
+
+- **数据迁移:** SQLite→PG 用 `pgloader` 命令行工具(一条命令搞定 schema+数据+类型映射)
+- **灰度:** 先让新 goosed 实例用 PG,老实例仍用 SQLite,流量按 session 分配。验证无误后全量切换。
+- **回滚:** PG 有完整 session 数据,可随时起新 SQLite 实例从 PG 导回。
+
+## 相关文档
+
+- [Goose Scale Architecture](goose-scale-architecture-2026-06-26.md) —— 背景与决策
+- [g2 Load Balancing](g2-load-balancing.md) —— 路由与灰度机制

docs/release-deploy.md

@@ -37,11 +37,13 @@ bash scripts/release-portal-runtime-prod.sh
 - 禁止 `bash scripts/release-prod.sh`（源码包发布已停用）
 - 禁止手工拖文件覆盖 103
 - 禁止在 103 直接改源码后继续跑
+- **禁止 SSH 到 105 直接改业务源码**（含 `scripts/wechat-mp-menu.mjs`）；见 [105 服务器变更规范](105-server-operations.md)
 - 禁止跳过备份和健康检查
 
 ## 相关文档
 
 - [Portal 无源码迁移说明](no-source-portal-migration.md)
+- [105 服务器变更规范](105-server-operations.md)
 - [开发环境规则](../DEVELOPMENT_RELEASE_RULES.md)
 - [测试发布规则](../TEST_RELEASE_RULES.md)
 - [生产发布规则](../PRODUCTION_RELEASE_RULES.md)

docs/service-isolation-runbook.md

@@ -20,6 +20,7 @@
 硬规则：
 
 - 不在开发预览中使用 `8081`、`3001`、`8090`。
+- **禁止 SSH 到 `105` 直接改业务源码**；105 是入口/代理层，变更须本地 commit 后发布。见 [105 服务器变更规范](./105-server-operations.md)。
 - 不在生产目录里跑会清理端口的开发脚本。
 - 不执行 `scripts/install-prod-services.sh` 来做开发预览；它会释放生产端口。
 - 不手动 kill `8081` 上的进程，除非目标就是恢复/重启生产，并且已经确认影响窗口。