macOS CI: build from the dev clone's engines, never from scratch past the 3h runner limit (L1.8)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

agents.md

@@ -137,6 +137,7 @@ packaging/linux/container.sh 命令  在 Ubuntu 26.04 镜像里运行（引擎
 tests/scripts/linux-glibc.sh     Linux 的应用、worker 与引擎要求的 glibc 不高于 2.43
 packaging/linux/package.sh 应用  出该应用的 AppImage、deb、rpm 与 Arch 包到 dist/（在容器里运行）
 packaging/source.sh dist        本提交的源码包与随包的 copyleft 上游源码（打过补丁的 MuPDF、Git），文件名带提交号；工作区有未提交改动即拒绝（macOS 的 release.sh 与 CI 的 Windows、Linux 调用）
+tests/scripts/ci-share.sh        ci.sh 只经指向 ELY_SHARE 的链接用共享引擎：自建目录、指向别处或目标带换行的链接即拒绝
 tests/scripts/linux-packages.sh  deb、rpm、Arch 包在干净的 Ubuntu 26.04、Fedora 44、Arch 容器里装上，每个 ELF 都找得到库
 tests/scripts/linux-pins.sh      Linux 打包工具（appimagetool、linuxdeploy、运行时、nfpm）的下载与钉的散列相符
 tests/scripts/linux-installed.sh installed|appimage  Hyprland 上装好的六个应用或 AppImage：一个窗口、随 Omarchy（Catppuccin）、读出页面文字（PDF、Markdown 经各自引擎），ElyTree 随换主题到 Latte（grim 按窗口截取）
@@ -294,7 +295,7 @@ cargo run -p ely-doc          启动一个应用（ElyDoc 先 cargo build -p ely
 - 2026-10-09：每个应用只跑一份（缺陷清单 X-03）。`ely_ui::run` 在写日志之前取应用数据目录的 `instance.lock`（`ely_platform::instance::hold`；Unix 为 fcntl 记录锁，进程结束即放，被拒时以 `F_GETLK` 向系统问出持锁的进程号，不另存进程号文件，同时启动的几份也报得准；Windows 为 LockFileEx，不报进程号）；已有一份在跑时第二份不启动，报“已在运行（进程号）”。原先第二份启动即清空第一份的工作目录、把它的恢复点当作干净结束删掉、改写崩溃锁。macOS 经访达打开文件本就交给运行中的那份；`open -n` 与 Linux 每文件一个进程时第二份被拒，文件须在已开的窗口里打开（未做转交）。`tests/scripts/one-instance.sh` 核对。
 - 2026-10-10：ElyMark 的链接（M-05，我定，同常见编辑器）：可视模式单击链接是编辑，Cmd 单击（Windows、Linux 为 Ctrl）交应用；预览单击即交应用；应用照 ElyPDF：http、https、mailto 交系统打开，其余提示拒绝。
 - 2026-10-10：Windows 与 Linux 的构建环境（E-01）。Windows：MSVC（VS 2022，v143）；MuPDF 由 `build-mupdf.sh` 以 MSBuild 编上游 `platform/win32` 的 `libmupdf`（静态运行库 /MT，同 Rust 的 `crt-static`；`HAVE_LIBCRYPTO`，`libmupdf.lib` 内含第三方、Tesseract 与 PKCS#7）；静态 OpenSSL 取自钉在 2026.07.29 的 vcpkg（`engines/vcpkg`，`openssl:x64-windows-static`）；Git 为 Git for Windows 的 MinGit 2.56.0（钉散列，`engines/git/cmd/git.exe`，LFS 在 `ucrt64/libexec/git-core`）；CEF 照 cef-dll-sys 放在可执行文件旁（Windows、Linux 都是），不另载入；`%TEMP%` 下的程序被系统的应用控制拦下，构建与探针都不放那里；cmake 与 ninja 须在 PATH；LibreOffice 的 configure 只认 VS 自带的 CMake（组件 `VC.CMake.Project`）。仓库与 `reference/` 一律 LF（`core.autocrlf false`、`core.eol lf`；`fetch-references.sh` 对每个上游照设）。Linux：WSL 的 Ubuntu 26.04；静态 libcrypto 另需其 pkg-config 列出的库（jitterentropy、zstd、z）。LibreOffice 在 Linux 照 Collabora 的 LOKit 配置构建（无图形后端、cairo RGBA、自带各库）。
-- 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、deb、rpm 与 Arch 包（引擎构建与打包都经 `packaging/linux/container.sh` 进 Ubuntu 26.04 容器，WSL 里须有 docker；`ELY_SHARE` 的目录一并挂进容器），都由 `packaging/stage.sh` 分装引擎；每个平台都上传本提交的源码包（`packaging/source.sh`）；更新清单只含 macOS（Windows 与 Linux 的自动安装未做）。
+- 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 的常驻克隆里借用开发克隆 `~/Documents/GitHub/ElyOfficeSuite` 的引擎（`ELY_SHARE`；2026-10-11 起：从零构建 LibreOffice 超过 act_runner 默认的 3 小时，v0.1.3 的 Mac 任务被杀、无 dmg），Windows 在本机运行器上把 `engines` 与 `reference` 接到开发克隆，Linux 由同一台 Windows 运行器经 WSL 构建（服务器上的 Linux 运行器是一次性容器，建不了内核）；各自打包后上传到该标签的发布。Windows 为 NSIS 安装程序，Linux 为 AppImage、deb、rpm 与 Arch 包（引擎构建与打包都经 `packaging/linux/container.sh` 进 Ubuntu 26.04 容器，WSL 里须有 docker；`ELY_SHARE` 的目录一并挂进容器），都由 `packaging/stage.sh` 分装引擎；每个平台都上传本提交的源码包（`packaging/source.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（用户报：Windows 上标题栏的最小化、最大化、关闭三个按钮都按不动）：gpui 回答系统的命中测试（`WM_NCHITTEST`）时按绘制次序取第一个含指针的窗口控制区，标题栏的拖动区先于其中的按钮画出，按钮上一律答“标题栏”，系统把按下当作拖动窗口的开始，点击到不了按钮。修复在 `vendor/gpui-pre`（原样一个提交，其后是修复）：按命中测试的次序取最上层的控制区，且只看未被遮挡的部分（同 `is_hovered`，盖在标题栏上的对话框挡住其下的按钮）。实测（发行构建，DPI 感知的探针移动真实指针）：自右向左依次答关闭、最大化、最小化、拖动；按下最小化即最小化，最大化即最大化，关闭即退出、worker 随之结束；v0.1.3 的安装版同一探针处处答拖动。该回调只有 Windows 平台调用。
@@ -309,3 +310,4 @@ cargo run -p ely-doc          启动一个应用（ElyDoc 先 cargo build -p ely
 - 2026-10-11（用户要求：Linux 不只 AppImage）：`packaging/linux/package.sh` 由同一个 AppDir 出四种包：AppImage，以及经 nfpm v2.47.0（钉散列）的 deb、rpm、Arch 包。包把 AppDir 的 `usr` 装到 `/opt/ely-office/<应用>`，`/usr/bin/<应用>` 为链接，桌面项与 512 像素图标在 `/usr/share`。依赖由 AppDir 里每个 ELF 所需而未随包的库，加 gpui 按名载入的 Vulkan 与 Wayland 客户端库得出：deb 与 Arch 按 `packaging/linux/depends.tsv` 换成包名（表里没有即打包失败），rpm 直接依赖库名（`libxcb.so.1()(64bit)`）。同级应用多找一处 `/opt/ely-office/<应用>/bin`（ElyMark 打开 ElyTree）。LibreOffice 的 cairo 由 meson 构建，内核直接拷其构建目录的产物，RUNPATH 仍指向构建树里的 pixman 与 fontconfig（别的机器上找不到）；`build-libreoffice.sh` 在 Linux 上把指向源码树的 RUNPATH 改为 `$ORIGIN`（patchelf）。
 - 2026-10-11：Linux 包的实测（L1.6）。本机（Omarchy，Hyprland 0.56）装上六个 Arch 包与六个 AppImage，`linux-installed.sh` 两种都过；deb、rpm、Arch 包在 Ubuntu 26.04、Fedora 44、Arch 容器里装上、全部 ELF 找得到库；deb 与 rpm 的六个应用在各自容器的 Xvfb 下画出窗口（`linux-distros.sh`）。截图按窗口（`grim -T` 加 Hyprland 的 `stableId`）：按区域截时用户切换工作区或别的窗口盖住即截错。ElyMark 的文件监视略去读取后不会自激：重读前先比指纹（长度与修改时间），不打开文件。
 - 2026-10-11（用户定：替换 v0.1.3 的 Linux 包）：v0.1.3 发布里原有的六个 AppImage（无头，打不开窗口）已删去，换成本机容器里建出的六个应用各四种包（共 24 个），出自 L1.7 的提交（晚于该标签）；上传后逐个核对大小，ElyTree 的 AppImage 下载回来散列相同。`package.sh` 把每个 RUNPATH 按所在 ELF 解析（`$ORIGIN` 或 `${ORIGIN}` 开头，规范化后须在 AppDir 内），否则拒绝（如未修正的 cairo）：CI 用的是别处建好的引擎，旧构建会在这里报错而不是带进包里。替换的 Linux 包对应的源码随之上传到同一发布（`source.sh`，文件名带构建提交号），发布说明写明 Linux 包出自哪个提交。
+- 2026-10-11：`ci.sh` 用 `ELY_SHARE` 时，CI 克隆里的 `engines`、`reference` 须是指向共享克隆的链接（Windows 为目录联接，不查）；是本克隆自建的目录或指向别处即报错，不混用。`.gitignore` 的 `/engines`、`/reference` 不带斜杠，链接也被忽略（`source.sh` 要求工作区干净）。