Files

T

john d7cbf3cc96 chore: add 105 runtime and openhands ops tooling

2026-07-01 18:10:48 +08:00

6.6 KiB

Raw Permalink Blame History

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 升级记录

本地开发仓库是 /Users/john/Project/Memind；生产 runtime 发布目标是 103。
105 上的文件是部署产物，不是编辑源。

禁止事项

以下操作一律禁止：

SSH 到 105 后直接改源码
包括但不限于：sed -i、vi/nano、echo >> file、手工上传单个 .mjs/.ts/.tsx 覆盖。
在 105 上改脚本后当作“已发布”
例如直接改 /root/tkmind_go/ui/h5/scripts/wechat-mp-menu.mjs 而不经过本地 commit 与发布。
把 105 当开发/调试环境
不在 105 上跑本地开发命令、试改业务逻辑、临时 patch。
绕过发布流程的“快捷修复”
“为了快”不是 SSH 直改的理由；违规改动会在下次发布时被覆盖，且与 Git 历史脱节。

允许的操作（只读与受控运维）

在不修改业务源码的前提下，允许：

只读排查：systemctl status、journalctl、健康检查 curl、查看目录结构
按 runbook 重启服务（需有文档依据，且变更本身不是改代码）
在发布已完成、脚本内容已与本地 commit 一致后，执行受控同步命令（见下文「服务号菜单」）

代码变更的正确流程

本地 test-memind 修改
  → 本地验证
  → Git commit（可追溯）
  → 按现行发布流程发布到目标环境（103 Portal runtime / 其他已文档化的入口）
  → 发布后健康检查与业务路径验收

105 Portal runtime 发布

105 上当前 H5 由 systemd 服务 goose-h5 运行，真实目录是：

/root/tkmind_go/ui/h5

发布 105 的 Portal / 微信服务号相关能力时，必须走 runtime artifact，不要直接发源码树：

cd /Users/john/Project/Memind

# 仅预演，不切换 live
bash scripts/release-portal-runtime-105.sh --dry-run

# 正式发布到 105
bash scripts/release-portal-runtime-105.sh --yes

这条发布链的关键规则

本地先把 server.mjs 与 mindspace-sandbox-mcp.mjs 打成 runtime bundle，再连同 dist/、public/、schema.sql、启动脚本一起打包。
不要把本机 Mac 的 node_modules 直接打进包发到 105。
105 是 Linux，像 @node-rs/argon2 这类原生依赖会因为平台不匹配而启动失败。
105 的 runtime 包默认不带 node_modules；切换前会在 105 本机执行：

npm install --omit=dev --no-package-lock

确保安装的是 Linux 可用依赖。 4. 发布时默认保留这些持久项，不覆盖：

.env
MindSpace/
data/
users/
logs/
public/plaza-covers/

发布完成后必须验：

ssh root@120.26.184.105 '
  systemctl is-active goose-h5
  curl -sf http://127.0.0.1:8080/api/status
'

正确结果应为：

goose-h5 = active
/api/status 返回 ok

禁止事项（105 runtime）

禁止把 node_modules/ 从本机打包后直接发到 105
禁止在 105 直接改 server.mjs / wechat-mp.mjs / scripts/wechat-mp-menu.mjs
禁止跳过健康检查就宣称“已发布”

服务号底部菜单（`wechat-mp-menu.mjs`）

菜单名称与链接定义在本地：

scripts/wechat-mp-menu.mjs

两层动作，不可混淆

步骤	做什么	在哪里做
1. 改菜单定义	修改 `MENU` 常量（如 `M广场` → `M发现`）	仅本地仓库
2. 同步到微信	调用微信 `menu/create` API	目标环境已发布后的机器上执行脚本

正确流程

# 1. 本地改 scripts/wechat-mp-menu.mjs
cd /Users/john/Project/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

禁止做法（反例）

# ❌ 禁止：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 / 改服务号菜单 / 改线上文案”类任务时：

先读本文与生产发布规则
在本地 test-memind 修改并 commit
走文档规定的发布流程
仅在发布后执行必要的 API 同步（如微信菜单）
不得 SSH 到 105 直接改 .mjs / .ts / 前端资源

6.6 KiB Raw Permalink Blame History Unescape Escape