diff --git a/agents.md b/agents.md
index 959708f..331d8a0 100644
--- a/agents.md
+++ b/agents.md
@@ -286,4 +286,5 @@ cargo run -p ely-doc          启动一个应用（ElyDoc 先 cargo build -p ely
 - 2026-10-10：Windows 与 Linux 的内核与 worker（W-01、K-01，用户定：0.1.3 先三端发布）。内核只认合并库（`ffi::KERNEL`：`libmergedlo.dylib`、`libmergedlo.so`、`mergedlo.dll`；`sofficeapp` 在合并构建里是文本占位）；Windows 载入时一并搜索该 DLL 所在的 `program/`。查找次序照旧，Windows 与 Linux 的包内位置是应用旁的 `libreoffice/program`，开发构建为 `engines/lo-src/instdir/program`。worker 的主循环：macOS 照旧以 GCD；Linux 以 unipoll，`runLoop` 的轮询回调里每次答一个请求，内核的唤醒回调往同一队列放信号（`worker/unipoll.rs`；回调的数据指针须非空，VCL 见空即不调用）；Windows 也以 unipoll：LOK 不另起主线程，worker 的主线程跑 `runLoop`（Windows 的消息循环），请求经只收消息的窗口投到这条线程上执行（`worker/messages.rs`），同 macOS 的 GCD；原先 LOK 自起主线程、worker 在另一线程作答，载入表格即死锁。Windows 的循环不调轮询回调，但须传非空的回调，`isUnipoll` 只看它。补丁 `0043-lok-callbacks-flush-inline-everywhere.patch`：回调队列在各平台都即时冲出（原只 macOS），否则请求里等的命令结果与状态要等下一轮主循环才到。`0042-svx-boost-json-needs-no-library.patch`：svxcore 与 sd 定义 `BOOST_ALL_NO_LIB`，MSVC 不再按 Boost 的自动链接索要 `libboost_json`、`libboost_container`。Linux 的内核以 cairo 画图块（worker 设 `SAL_DISABLESKIA`；构建去掉 `--enable-cairo-rgba`，自带的 cairo 要清掉重建），字节为 BGRA，同 macOS 与 Windows；`getTileMode` 只看 cairo 开关，不可信。worker 启动核对在三端都画一段红字，按 BGRA 找不到红色即拒绝。`scripts/apply-lo-patches.sh` 的临时库设 `core.autocrlf false`（Windows 默认转换使任何前缀都对不上）。Windows 的 LibreOffice 在 Cygwin 下构建（`build-libreoffice.sh` 的 CYGWIN 分支：去掉 Unix 专用开关，加 VS 2022，用 `/opt/lo/bin` 的 make，清掉 Git Bash 带进来的 `MSYSTEM`）；构建目录与 Cygwin 排除在 Defender 扫描之外（否则并行 configure 删不掉 `conftest.dir`）。英文词典扩展里的 Lightproof（Python 写的语法检查）在构建后删去：macOS 与 Linux 的内核不带 Python，它本不生效；Windows 必带内置 Python（Cygwin 下 configure 不许去掉），第二次用同一配置启动时初始化它，worker 挂起。worker 以 `SAL_NOLOCK_PROFILE` 运行，`ely.xcd` 关掉 LibreOffice 的文档锁（`Common/Misc/UseLocking`）：被强杀的 worker 留下的锁会让下次启动或载入弹出交互而挂起；每个应用只有一个 worker 用自己的配置，冲突由 Ely 自己核对。三端发布（CI-01）：`.gitea/workflows/release.yml` 在打标签时于三台运行器上执行 `scripts/ci.sh`：macOS 在 Mac mini 的常驻克隆里按需从零构建引擎，Windows 在本机运行器上把 `engines` 与 `reference` 接到开发克隆，Linux 由同一台 Windows 运行器经 WSL 构建（服务器上的 Linux 运行器是一次性容器，建不了内核）；各自打包后上传到该标签的发布。Windows 为 NSIS 安装程序，Linux 为 AppImage，都由 `packaging/stage.sh` 分装引擎；更新清单只含 macOS（Windows 与 Linux 的自动安装未做）。
 - 2026-10-11：gpui 的 Windows 窗口关闭（W-03 冒烟查出）。`gpui-pre-windows` 0.3.8 在窗口关闭时报三条错：系统已销毁窗口（ElyTree 的关窗交给系统）后 Drop 仍对旧句柄 `RevokeDragDrop` 与 `DestroyWindow`（拖放处理器因此不释放，连带窗口状态）；销毁时的失活回报排在异步任务里，执行时窗口已移除（“window not found”）；退出后后台任务向已销毁的平台窗口投递（`Invalid window handle`）。修复在 `vendor/gpui-pre-windows`：`WM_DESTROY` 时记下已销毁、在句柄仍有效时撤销拖放、去掉失活回调，Drop 见已销毁即不再动句柄；平台窗口已不在时投递失败只记 debug（应用已退出），其余投递失败照报。三个应用关窗与退出的日志无错。
 - 2026-10-11（用户报：Windows 启动带黑色命令行窗口、“打开方式”里无图标、点 X 不退出、表格全黑无网格线）：四处根因。命令行窗口：应用是控制台子系统；发行构建改为 `windows_subsystem = "windows"`（开发构建照旧有控制台看日志），子进程（两个 worker、Git、`cmd start`）一律经 `ely_ipc::windowless` 以 `CREATE_NO_WINDOW` 启动。图标：exe 里只有 gpui 的清单资源；各应用共用构建脚本 `packaging/windows/icon.rs`，把 `assets/icons/<应用>.ico` 编成资源 1（gpui 的窗口图标也取资源 1）。点 X 不退出：窗口其实弹了“保存更改”询问。`ely.xcd` 深色方案的 `CalcNotesBackground` 与浅色不同，Calc 在配色变化时改写批注样式并记一步撤销（`ScDetectiveFunc::UpdateAllComments`），未动的表格切到深色即算已修改；两套方案的批注底色改为同一值（LibreOffice 默认的浅黄），切换主题不再改文档，三端同此（`sheet.rs` 的 `a_theme_switch_is_no_edit`）。全黑：Win32 的虚拟设备没有 `SetSizeUsingBuffer`（基类默认返回假，断言在发行构建里不在），给客户缓冲区的设备停在 1×1 像素，Calc 图块只画了一个像素，放映图层同空；补丁 `0044-lok-win32-paints-then-copies.patch` 让 Windows 走 macOS 的路：按全尺寸画进设备，再拷进客户缓冲区（`doc_paintTile` 与 `SlideshowLayerRenderer`）。Writer 自设设备尺寸，原本不受影响。`tests/scripts/lo-patches.sh` 的临时库也设 `core.autocrlf false`（原先在 Windows 上恒失败）。
+- 2026-10-11：ElyMark 的 AppImage（0.1.3 的 Linux 发布查出）。`linuxdeploy` 把可执行文件的 RUNPATH 改成 `$ORIGIN/../lib`，并把它找得到的 `libcef.so` 拷进 `usr/lib`：原先 `libcef.so` 与 CEF 的资料在 `usr/bin`，结果是两份 1.45 GB 的内核、程序载入 `usr/lib` 那份、CEF 在它旁边找不到 ICU 数据而退出（从未在 AppImage 里启动过）。现在 `appimage.sh` 把从 `engines/cef` 分装来的全部条目移进 `usr/lib`（按名字对照 CEF 文件夹，清单仍只在 `stage.sh`），以 `LD_LIBRARY_PATH=AppDir/usr/lib` 运行 `linuxdeploy`，`libcef.so` 只此一份、依赖照样带上，CEF 按所载 `libcef.so` 的文件夹取资料（`ely-web-content` 的 `open`）。ElyMark 的 AppImage 由 715 MB 降到 423 MB；WSL 里启动后 CEF 载入、窗口打开（WSL 里各应用都不出首帧，未在真桌面上验证）。
 - 2026-10-09（用户定）：代码与发布从 GitHub 搬到自建的 Gitea（git.zacharyzhang.com；GitHub 账号被封，推送与发布都被拒）。公开仓库 `ZacharyZhang-NY/ElyOffice`（原样推上 main、缺陷清单分支与 v0.1.0、v0.1.1 标签），组件库为同站的 `ZacharyZhang-NY/Ely-GPUI-Components`（Cargo 的 git 依赖与 `fetch-references.sh` 随之改址，钉的提交不变）。v0.1.1 的六个 dmg 与两个源码包重新发在 Gitea 的 v0.1.1 发布里。官网的下载与源码链接指向 Gitea（`releases/latest` 会跳到最新发布页）。`.github/workflows` 删去（它们靠 GitHub 的 macOS 机器与 `gh`，发布改在本机以 `packaging/macos/release.sh` 构建、经 Gitea API 上传）。发布视频里写的地址已在源文件改为 Gitea，已发布的成片仍是旧地址，重渲染后才更新。上游项目（LibreOffice、MuPDF、git-lfs、tessdata 等）照旧从它们自己的 GitHub 地址取。
diff --git a/packaging/linux/appimage.sh b/packaging/linux/appimage.sh
index dac4056..309ac8e 100755
--- a/packaging/linux/appimage.sh
+++ b/packaging/linux/appimage.sh
@@ -88,11 +88,19 @@ for helper in ely-lok-worker ely-pdf-worker; do
   fi
 done
 if [ -f "$bin/libcef.so" ]; then
-  deployed+=(--library "$bin/libcef.so")
+  # Binaries here load from usr/lib; CEF's data sits with libcef.
+  cef=${ELY_CEF:-$root/engines/cef}
+  mkdir -p "$appdir/usr/lib"
+  for item in "$bin"/*; do
+    if [ -e "$cef/${item##*/}" ]; then
+      mv "$item" "$appdir/usr/lib/"
+    fi
+  done
+  deployed+=(--library "$appdir/usr/lib/libcef.so")
 fi
 
 # linuxdeploy bundles libraries and fails on a missing one.
-"$deploy" --appimage-extract-and-run --appdir "$appdir" "${deployed[@]}" \
+LD_LIBRARY_PATH=$appdir/usr/lib "$deploy" --appimage-extract-and-run --appdir "$appdir" "${deployed[@]}" \
   --desktop-file "$work/$slug.desktop" --icon-file "$icon"
 
 mkdir -p "$dist"