diff --git a/CHANGELOG.md b/CHANGELOG.md
index d4fd43c..5f8146f 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,5 +1,26 @@
 # 变更记录
 
+## 2026-08-24（晚，续）— 更正：不是"另一个并发会话"，真凶是 PM2 自动重启 + 找到彻底止血办法
+
+**更正上面那条记录里"另一个并发会话手动启动/又手动拉起来"的归因是错的**——用户明确说这台机器
+当时只有他自己在用，没有别的同事。停了 minimax-h3 之后它反复自己重新起来，一路排查（cron/
+systemd/tmux/screen/supervisor 都查过一遍确认没有）才找到真正机制：
+
+- `stable-diffusion-webui-forge` 和一个 embedding 服务（`m3e`）是被 **PM2**（系统级 Node.js
+  进程管理器，`pm2 list` 能看到，跑了75小时，跟这次任何工作都无关，是机器本来就有的基础设施）
+  托管的，子进程被 kill 掉 PM2 会自动重启——这才是"杀了又起"的真正原因。已经
+  `pm2 delete sd-forge m3e && pm2 save`，从 PM2 的常驻列表里彻底删掉（`pm2 save` 很关键，
+  不然重启/`pm2 resurrect` 还会把它们从旧快照里救回来）。
+- `minimax-h3` 的 `gateway.py`/`api.py` **不在** PM2 管理范围内（`pm2 list`/root 的 PM2 实例
+  都确认过没有它），真正触发重启的机制没有查到——但既然查不到，就换一个不用管触发源是什么
+  都生效的办法：把 `api.py`/`gateway.py` 直接改名成 `.disabled-20260824`，`python -m uvicorn
+  api:app` 这个 module import 从根上就会失败，不管是谁/什么在尝试重新拉起，都会失败。改名
+  后观察 45 秒，四卡显存稳定在基线（160-162MB），没有再出现任何重启尝试。
+
+**结果**：GPU 彻底清空，raylight/console 全程未受影响（验证过 `/health` 一直正常）。这个
+问题从"以为是同事"到"查到 PM2"再到"minimax-h3 单独用改名兜底"，全程记录留着——如果以后再
+遇到类似"进程杀了又起"的情况，**先查 `pm2 list`**，比查 cron/systemd 更容易先想到。
+
 ## 2026-08-24 — 下线旧 H3（minimax-h3）+ 确认 LLM 早已下线，GPU 显存全部还给 raylight
 
 **背景**：排查一次 raylight 的 CUDA OOM 时发现 GPU1 被另一进程占着 16.7GB、98%利用率——
diff --git a/CLAUDE.md b/CLAUDE.md
index 4a8f8e6..8a3eecd 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -84,7 +84,7 @@ cat llm-setup.md | ssh -o ControlPath=~/.ssh/cm67 admin@192.168.110.67 'cat > /h
 |------|--------|----|------|------|
 | `deploy-scripts/` | Qwen3.8-27B-Q5_K_M（llama.cpp，容器 `llm38`） | 0-3 分片 | **57.3 GB**（256K 上下文，2 槽位） | 8000 → `qwen.wudaima.com` |
 | `raylight/` | **2026-08-22 起 h3-console 的默认后端**：ComfyUI + Raylight 插件，4卡当一个 FSDP 集群跑 MiniMax-H3（不是4个独立worker，任何时刻只处理1个请求）。`server.py`（8100）对外契约兼容旧 `gateway.py`+`api.py`，管理常驻 ComfyUI 进程（8188，仅内部） | 0-3 全部（FSDP集群） | 832×480×64帧实测峰值约20-21GB/卡；**124帧会OOM**，见 `raylight/README.md`「已知限制」 | 8100（内部，h3-console 的 `H3_GATEWAY_URL` 指向这） |
-| `minimax-h3/` | **热备份（2026-08-24 起启动脚本被禁用）**。MiniMax-H3 FL2VA/Ref2VA NF4 文生视频，`api.py` 四实例（GPU0-3，端口 8010-8013）+ `gateway.py` 调度层（端口 8000），四卡各自独立能同时处理4个请求。代码/权重保留，但 `start-all.sh`/`start-gateway.sh` 已改名成 `.disabled-20260824`（见目录内 `DISABLED-README.md`）——2026-08-24 发现有人手动拉起来跟 raylight 撞 GPU，停了两次又被拉起来，直接禁掉启动脚本，别再凭记忆当"还能秒级拉回"用 | 四卡各一进程（停着，脚本已禁用） | 单卡 fp32 峰值约 9-14 GB（视时长/分辨率），另占 CPU 内存约 32 GB/worker | 8000（停着） |
+| `minimax-h3/` | **热备份（2026-08-24 起彻底禁用，双重保险）**。MiniMax-H3 FL2VA/Ref2VA NF4 文生视频，`api.py` 四实例（GPU0-3，端口 8010-8013）+ `gateway.py` 调度层（端口 8000），四卡各自独立能同时处理4个请求。代码/权重保留，但 `start-all.sh`/`start-gateway.sh` 和 `api.py`/`gateway.py` 本体都已改名成 `.disabled-20260824`（见目录内 `DISABLED-README.md`）——2026-08-24 反复出现"停了又自己起来"，查了半天不是 cron/systemd，也不是 PM2（那两个是 sd-forge/embedding 的事，见下），真正触发源没查到，干脆把 `api.py`/`gateway.py` 本体也改名，`python -m uvicorn api:app` 从 import 这层就会失败，不管谁/什么在尝试重启都没用。别再凭记忆当"还能秒级拉回"用，得先把三份改名的文件都恢复原名 | 四卡各一进程（停着，彻底禁用） | 单卡 fp32 峰值约 9-14 GB（视时长/分辨率），另占 CPU 内存约 32 GB/worker | 8000（停着） |
 | `h3-console/` | H3 Web 管理台：上传/生成/预览三界面 + 任务持久化。两个进程共享同一份 sqlite/assets：**8080**（局域网直连，`BASE_PATH` 空）+ **8081**（`H3_CONSOLE_BASE_PATH=/console`，专供公网子路径用）。**2026-08-22 起两个实例的 `H3_ENABLE_SUPERVISOR` 都关了**——fl2va/ref2va 弹性调度器（按partition flip某张卡）是给 minimax-h3 那套"4个独立worker"架构设计的，raylight 的FSDP集群架构下没有"单卡分区"这个维度，开着会出错 | 不占显存（自己不跑模型） | — | 局域网 `http://192.168.110.67:8080`；公网 `http://qwen.wudaima.com/console`（frp `locations=/console` 分流，`gateway.wudaima.com` 那条独立域名确认走不通，缺口在 frp 服务端 60.205.214.169，见 CHANGELOG） |
 
 ⚠️ **"（常驻）whisper GPU3 3.2GB"这条 2026-08-24 确认是过期信息**——当时机器上根本没有任何
@@ -133,9 +133,12 @@ stable-diffusion-webui-forge`）和一个 embedding 服务（gunicorn:7590），
 **2026-08-24 更新：LLM（`llm38`）和旧 H3（`minimax-h3` 的 `gateway.py`+`api.py`）都已下线，不占显存**。
 `llm38` 容器 `docker ps -a` 显示 6 天前就已经停了（`Exited (0)`），不是本次操作停的，只是文档一直
 没更新——`qwen.wudaima.com` 现在实际上是打不通的，上面这段"对外服务中"的描述已经过期。
-`minimax-h3` 的四个 worker（8010-8013）+ `gateway.py`（8000）是本次手动按端口 `kill` 停的——
-之前被另一个并发会话手动启动过，跟 raylight 抢过 GPU（详见 `raylight/notes.md`/`CHANGELOG.md`
-2026-08-24 那几条）。**现在这台机器上生产只跑 `raylight/`（h3-console 默认后端）**，代码/权重
+`minimax-h3` 的四个 worker（8010-8013）+ `gateway.py`（8000）是本次手动按端口 `kill` 停的，
+停完反复自己又起来——**一开始误以为是别的并发会话在手动重启，后来确认这台机器当时只有一个人
+在用，排查出真正原因是 PM2（系统级进程管理器）在管另外两个不相关的服务（sd-forge/embedding），
+已经 `pm2 delete`+`pm2 save` 处理掉；`minimax-h3` 本身的重启触发源没有查到，改用把
+`api.py`/`gateway.py` 本体也改名的办法从根上堵死**，完整排查过程见 CHANGELOG 2026-08-24
+「更正」那条。**现在这台机器上生产只跑 `raylight/`（h3-console 默认后端）**，代码/权重
 都还在，两条线要拉回来都还是走各自的 `start.sh`/`docker start llm38`，没有删任何东西。
 
 ## 这是一台测试机（2026-08-18 用户明确）