john
7.5 KiB
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 / 其他已文档化的入口）
→ 发布后健康检查与业务路径验收
相关规则入口：
不要使用已停用的 rsync_to_server.sh 或直接 rsync 到 105 作为常规发布手段（见 PRODUCTION_RELEASE_RULES.md）。
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. 发布时默认保留这些持久项，不覆盖：
.envMindSpace/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 - 禁止跳过健康检查就宣称“已发布”
103 Portal 用户灰度的 105 入口切换
103 Portal 灰度不发布业务源码到 105。正式入口由已提交的
scripts/release-portal-canary-prod.sh 受控变更：
- 先备份并校验 105 活动的
m.tkmind.cn.conf与wechat.m.tkmind.cn.conf。 - 在 103 启动独立路由器
18082，并通过反向隧道只暴露为 105 本机19082。 - 候选、身份路由和隧道全部通过后，脚本才把两份 nginx 上游从
58.38.22.103:8081切到127.0.0.1:19082。 - 必须先
nginx -t，再 reload，并在切换后主动证明候选故障会回落稳定 8081； 任一步失败恢复备份并回到稳定入口。 - 回滚只能使用
scripts/rollback-portal-canary-prod.sh，禁止在 105 手工sed -i。
该动作属于 commit、CI、完整 Gate report 和明确生产批准约束下的正式发布运维， 不构成允许在线编辑 105 配置源码的一般例外。
服务号底部菜单（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/ 前端资源