R8.1: document content keeps the file's colours in a dark app

Pages, cells, slides and PDF pages paint as the file says in any
appearance; only the chrome around them follows dark mode. The
kernel keeps Ely's one light scheme, sent once a view, and MuPDF
no longer inverts. Reviews now run gpt-6.1-sol at xhigh.

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

agents.md

@@ -123,7 +123,7 @@ scripts/fetch-references.sh    取上游源码到 reference/
 scripts/fetch-tessdata.sh      取 OCR 语言数据到 engines/tessdata（钉提交，核对散列）
 scripts/build-git.sh           构建钉住的 Git 到 engines/git（ElyTree 随包）
 scripts/fetch-git-lfs.sh       取 git-lfs 放进 engines/git（核对散列）
-scripts/review.sh ID 轮次 路径  审查一条任务（herdr 右侧分栏，codex gpt-6-astra，effort max，fast）
+scripts/review.sh ID 轮次 路径  审查一条任务（herdr 右侧分栏，codex gpt-6.1-sol，effort xhigh，fast）
 scripts/apply-lo-patches.sh engines/lo-src  找出源码已到补丁序列第几个，补上其余（构建脚本调用）
 tests/scripts/lo-patches.sh    补丁序列从中途接着打、再打一次为空操作
 tests/scripts/media-targets.sh 媒体播放接口在 Linux、Windows 目标可编译（缺目标时 SKIP）
@@ -213,7 +213,7 @@ cargo run -p ely-doc          启动一个应用（ElyDoc 先 cargo build -p ely
 - 2026-10-05（用户定）：ElyAgent 的后端与内置模型的登录配置以 Kigi CLI（https://git.zacharyzhang.com/ZacharyZhang-NY/Kigi-CLI，Rust）为基础，以 Rust 依赖直接嵌入，不用 ACP；沿用其提供商登录（订阅账号或 API 密钥）与模型配置。
 - 2026-10-05（用户定）：八个应用都不许卡顿：键入、选择、滚动、文档渲染都要即时（GPUI 的 120 FPS 手感），树莓派 3 上也要流畅。输入延迟与帧时间是验收项，要实测；界面线程不等内核、不持 worker 锁做同步请求，空闲不做事。
 - 2026-10-05：LOK 的输入与事件路径（实测后定）。原样：视图的事件监听长轮询 worker（持 worker 锁最多 50 毫秒，worker 读线程也随之阻塞最多 250 毫秒），按键排在锁后，键入锁等待中位 290 毫秒、最长 9 秒；输入队列在界面执行器上逐条跳回界面线程，每键约一帧，连续键入积压到 1 至 2 秒。现在：worker 有新事件即主动推送（`tag::EVENTS`，推送线程在输出锁下取批，批次即发送时状态），客户端读线程把回复与事件分开，事件存入 `client::Feed`，视图以异步方式等它（`Feed::next`，有新批次时唤醒，不占线程、不碰 worker 锁；原先每个打开的文档阻塞一个后台线程最多一秒，文档多于核数时会饿死输入与图块；监听任务归视图所有，视图释放即停）；每个视图一条后台通道（`view/lane.rs`），输入优先、图块其次，连续执行，界面线程只收落地结果；文档尺寸与页框只在内核报尺寸变化时在后台读；批次弄脏的已显示图块即刻重绘，不等下一帧；视图的 `Reported` 事件只在内核回报或输入落地时发出，滚动与图块到达不触发应用的观察钩子；编辑与光标移动后应用要读的内核列表（ElyDoc 导航、字数、审阅，ElyTable 工作表与几何、单元格规则、格式面板）经 `ely_lok::read_off` 在后台读，一次一个，结果按发起者核对。实测（macOS，`tests/scripts/lag.sh`）：按打字速度键入时输入落地 0 至 1 毫秒，图块 1 至 3 毫秒，按键到新图块 ElyDoc 中位 19 毫秒、ElyTable 3 毫秒；连续快速键入（脚本一次送出近百字）时，各次运行在 3 至 225 毫秒的中位之间摆动：新文档首次键入时内核有一次 150 至 230 毫秒的冷启动（首块图块与拼写等初始化），同一批字排在它之后；原为中位 1 秒、p95 1.9 秒。树莓派 3 未实测（本机无设备）。界面线程不碰 worker：应用对内核的读取、保存与另存为的导出、导出 PDF、比较、邮件合并都经 `Tabs::read_in`（或 `ely_lok::read_off`）在后台执行，回到窗口时按发起的标签与读取时的状态核对；保存导出期间标签状态为“正在保存”，同一标签的后续保存排队到它结束；另存为在写入前按文件身份再查一次目标是否已被别的标签持有；导出期间又有编辑时，“保存后关闭”不关闭，回到关闭询问；关闭标签时的撤销历史也在后台读；邮件合并预览与比较在发起时就保留自己的标签号与工作目录；读取失败不立即重试，等下一次状态变化；载入时一并在后台读版面与撤销历史（`ely_lok::layout`，`LokView::open` 接收版面）。窗口关闭回调先不放行，在后台逐个读标签的撤销历史并关闭（有改动的照常询问），最后一个标签关闭后移除窗口；内核文档的关闭也在后台（2026-10-06 起，原先同步读历史、在界面线程持 worker 锁关闭）。
-- 2026-10-04（用户定）：八个应用的内容区一律随系统深浅色：Doc 页面、Table 网格、Show 幻灯片、PDF 页面、邮件正文、Mark 编辑区、Agent 输出。自动颜色随之翻转，文件里写明的颜色照原样；打印与导出 PDF 仍为浅色。各引擎（LOK、MuPDF）接入应用主题，不留引擎默认色。LOK：`ely.xcd` 定义 `COLOR_SCHEME_ELY_DARK` 与 `COLOR_SCHEME_ELY_LIGHT`（文档底色、自动文字色、网格、链接等取 Ely 默认色板；内核自带的深色方案颜色留空、按应用外观取默认值，传方案名不改外观，所以不用它），`LokView` 在主题深浅变化时经有序队列发 `.uno:ChangeTheme`（不算编辑），页面底色深色取 `surface`、浅色取 `paper`；Omarchy 色板与这两套固定色可能略有差别。导出 PDF 实测仍为白底。图块作废时旧图仍显示，新图到达后替换，编辑与主题切换都不闪。
+- 2026-10-04（用户定），2026-10-18 改（用户定）：Doc 页面、Table 单元格、Show 幻灯片、PDF 页面在任何外观下都照文件原色（白底即白底），只有页面四周的界面随深浅色；邮件正文、Mark 编辑区、Agent 输出随系统深浅色。LOK：`ely.xcd` 只有 `COLOR_SCHEME_ELY_LIGHT`（文档底色白、自动文字色黑、网格、链接等）；方案按视图记（LOK 下全局改动只作用于当前视图），每个 `LokView` 首帧经有序队列发一次 `.uno:ChangeTheme`（`ely_lok::SCHEME`，不算编辑），ElyShow 放映与输出的副本同样各发一次；旧版写进内核配置的 `COLOR_SCHEME_ELY_DARK` 已删，内核读不到即退回自动方案，首帧的那次改回 Ely 方案。页面底色 `ely_lok::paper()` 为白，同方案的 `DocColor`。MuPDF 照原样画，不反相。图块作废时旧图仍显示，新图到达后替换，编辑不闪。
 - 2026-10-01：主题。`Appearance` 为系统、浅色、深色。系统档在有 Omarchy 时跟随 Omarchy（`ThemeSettings::omarchy_sync`）。读 Omarchy 的 `$HOME/.local/state/omarchy/current/theme/colors.toml`（Omarchy 写死此路径，不随 `XDG_STATE_HOME`），目录由 `ELY_OMARCHY_DIR` 可改。读法与回退链照 `reference/omarchy/bin/omarchy-theme-color`：松散引号、`colorN`、`purple`、`selection_background`、`theme_type`、`light.mode`、亮度和 382 比。缺的色相用 Ely 自己的色并警告。色板照组件库 `A11yChecker` 的规则收口：正文、状态色、代码色在各自的表面上 4.5:1，焦点与图表色在页面上 3:1；先拉近前景再拉到纯黑白，最后逐项核对，核对不过的主题整套忽略。切换时 Omarchy 先暂存 `next-theme` 再整体替换 `theme`，用文件监视跟随，不用它的钩子。新主题无 `colors.toml` 时退回 Ely 色板。`ELY_APPEARANCE`、`ELY_OMARCHY_SYNC`、`ELY_REDUCE_MOTION` 是覆盖开关，设置页接入前先用环境变量。
 - 2026-10-05：组件库 8658999（组件库重写历史后的 main，加本项目三个提交）：属主不经 `Close` 移除的浮层（一起移除的嵌套浮层同样，回到最外层打开前之处）（对话框动作只清自身状态、异步校验通过后才关）照样把焦点交回打开前之处；原先焦点落在根上，键入无处可去，须先点一下网格。同批带入上游的 ColumnShell、输入法组字时光标重新闪烁、`Icon::from_path`、MIT 许可。旧 pin 2f02c82 已不在 main 上，只能按完整哈希取得。`Select::label` 与 `TextInput::label` 给控件无障碍名称而不绘制；对话框里描述列表旁的控件以此命名，开关用自身的 `label`。7186179 加 `NumberInput::label`（经内部文本框的 `TextInput::set_label`），同批带入上游的 rustfmt 修正。80c46b1：`TemplatePicker` 的列表是一个 Tab 停靠点，上下、Home、End 移动，回车使用，行带列表项语义，搜索提示、全部、使用、无匹配的文案进内建中英目录。7df3045：`SelectableList` 在 AX 树里是列表（`label` 命名），`ListItem` 是列表项（标题为名，带说明、选中、在可选列表中的序号与总数）；原先行无角色，不在 AX 树里。af54877：`NumberInput::blank` 显示占位文字而非数字（混合选区），空着回车或失焦不提交，键入后照常。408f2b0：`CommentSidebar` 与 `RelativeTime` 的文案进内建中英目录；属主不处理“解决”时（无 `on_resolve`）不分未解决与已解决，一列显示全部。bcf0378：`CommentSidebar` 的批注列是列表，每条是 Tab 停靠点（列表项语义，名为作者与正文，带选中、序号与总数），回车或空格选中。71bfc93：`init_for_tests`（`test-support` 下）装主题与键位、不要资源，应用单测可渲染 Ely 组件。617a8d6：`FindWidget` 在查询框里按 Esc 即关闭（调 `on_close`）。2ce3368：`ContextMenu` 可定宿主大小。3d08744：`DescriptionList` 的值占满所在列，其中的文本框随之全宽；同批带入上游的图表、分页改动。a6b1bb0：`SignaturePad` 的“在此签名”与“清除”进内建中英目录；同批带入上游 P01 至 P15（各组件的越界与失效状态记日志而不 panic）。490b022：`ChangesList` 分列冲突、已暂存、改动、未跟踪、已忽略（各有其动作：冲突与已忽略只可打开），标题与提示进内建中英目录；同批带入上游 P16 至 P20。7bb53f4（ElyTree 用）：`ChangesList` 行数可缺、按区报按下、当前行；`DiffViewer` 外算的段、块按钮、可选的变动行、逐行读给辅助技术；`CommitList`、`FileHistory`、`BlameView`、`ThreeWayMerge` 只画可见行，`CommitList` 近尾加载；`DescriptionList::text`；`SegmentedControl` 各段为单选；`BranchList`、`TagList` 可选中、只画属主处理的行内动作；`marked`、`conflicts`、`resolve` 按标记宽度（`MARKER` 为默认 7），a284c71 起只按 LF 断行；c5799cc：`StashList` 文案进内建中英目录，行可选（`selected`、`on_pick`），只画属主处理的行内动作；7fab072 至 3741d5d：分支、标签、储藏的行分两行（上行名称与行内动作，下行说明与行尾文字），窄时名称与说明先让；行内动作一律显示（原先只在悬停时显示，键盘停在其上时看不见），改动列表同；各 git 行带透明的 1 像素边框，焦点框才画得出（原先 `focus_ring` 无边框宽度，键盘焦点不可见）；同批带入上游 P21 至 P29。4f8f3bd：`Changed::lines` 可缺（二进制文件、文件夹不计行数，不显示）；37c5187 缩短其注释。19b0b29：`DiffViewer::from_stretches`（别处算好的差异，如 Git 自己的）、`hunk_action`（每块标题上一个按钮）、`selected` 与 `on_line`（改动行可按，带 Shift），`diff::mark_words` 给外来的行标出改动的词，“行内”“并排”“N 行未改动”进内建中英目录；30fea9e：有块按钮时各行同高，底色相接。edd2c12：`ChangesList` 每次按下带分区（`ChangeSection`），行是 Tab 停靠点（列表项语义），`selected` 标出当前文件。2e080b8：`SegmentedControl` 每段是单选按钮（名为其文字，带选中状态），原先不在 AX 树里。e226d79：差异查看器的行模型与配色移入 `git/rows.rs`（文件不超过 500 行）；7b807a9 缩短其注释。51d2aea：`CommitList`、`FileHistory`、`BlameView` 只画视口内的行（`uniform_list`，填满所在的框；`CommitList` 收 `Rc` 的提交与 `lanes` 算好的图，`on_end` 在接近末尾时要下一页），各行是 Tab 停靠点（列表项语义，选中状态；Blame 每段首行可按，名为作者、时间与摘要），`FileHistory` 的行数可缺；`CommitInput` 的“提交到”“修改最近提交”进内建中英目录。e6220ad 与 3fc5a46：提交行窄时作者、提交号与时Line truncated
 - 2026-10-05：ElyTable 透视表与图表（C09.4，TABLE-10、11）。补丁 `0019-lok-calc-pivot-tables.patch` 与 `0020-lok-calc-charts.patch`：`.uno:DataPilotExec` 收 `Pivot`（JSON：源区域、行、列、筛选、值字段与函数 sum/count/average/max/min），光标在透视表上即原地修改，否则从源区域在新工作表创建；行、列、筛选里的空名表示内核的数据布局字段（多个值字段横排或竖排的位置），读出与写回都保留，已在表中的行、列、筛选字段保留各自的小计函数，读出的布局原样写回不改表；照内核布局对话框的步骤（`ConvertOrientation`，保留各字段的成员、排序与版式），新表的筛选按钮、钻取、展开收起都关（同对话框初值）；放到新工作表时插表与透视表是两步撤销（同桌面版）。刷新 `.uno:RecalcPivotTable` 在内核里本就不进撤销（它改缓存）。`.uno:InsertObjectChart` 收 `Chart`（JSON：类型 column/bar/line/scatter/pie、标题、图例、X/Y 轴标题；`other` 保持原类型），LOK 下不开图表向导、插入为一步撤销、插入后图表选中；给出的区域每段都要解析得了、所指工作表都要存在，否则插入与修改都拒绝、文档不动（内核原会改用示例数据，修改时 `ChartModel::setArguments` 抛出未捕获的异常使 worker 退出）；`.uno:ChangeChartData` 也收 `Chart`，区域与外观合成一步撤销（撤销保存整个图表的图示与主标题的副本，堆积等外观以外的设置一并恢复）（列表动作带当前视图号，否则 LOK 拒绝撤销别的视图的动作）。读取：`.uno:Chart`（选中图表的对象名、区域、表头、外观）、`.uno:PivotTable`（光标处透视表的名称、位置、源区域、字段与布局），`.uno:SelectedRange` 加 `data`（选区内数据的绝对区域）。界面在“插入”菜单：数据透视表、刷新数据透视表、图表；对话框在光标处有透视表、或有选中图表时为修改，否则以选中的数据（单格扩到数据区）新建，源与图表区域取 `data`，不含空行。为对话框发起的读取（`Tabs::ask_in`）回来时，发起的工作簿已不是当前标签即丢弃，不为隐藏的工作簿开对话框（ElyTable 全部对话框、合并询问）。没有数据时恢复原光标（`select.data` 会把单格标成区域，回车随之只在格内打转）。公式语法是 Excel A1，区域写 `Sheet1!$A$1:$C$5`。
@@ -277,7 +277,7 @@ cargo run -p ely-doc          启动一个应用（ElyDoc 先 cargo build -p ely
 - 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`）；`%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 的常驻克隆里借用开发克隆 `~/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` 分装引擎；本提交的源码包只由 Linux 上传（`packaging/source.sh`；macOS 照建供 `release-macos.sh` 核对，不上传，两端并行时不重复；Windows 的检出把符号链接写成文件，不出）；重跑时所传文件有任一同名的已在发布里即失败、什么也不传，写明须先删去哪些（重建的字节不同，更新清单的散列会对不上已在的 dmg）；更新清单只含 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 启动带黑色命令行窗口、“打开方式”里无图标、点 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 默认的浅黄），切换主题不再改文档，三端同此（2026-10-18 起只剩浅色方案，`sheet.rs` 的 `the_scheme_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 平台调用。
 - 2026-10-11：Linux 标题栏按钮（核查 Windows 按钮问题时查出）。macOS 的红绿灯由系统画，不受影响；Linux 为客户端装饰，按钮由组件库画在标题栏的拖动区里，拖动区对任何按下都准备移动窗口，按住按钮时指针动一像素即开始移动窗口，合成器接管指针，松开到不了按钮，点击落空。组件库 3eb4d34：`drag_region` 只在按下未被里面的按钮认领（按钮以 `prevent_default` 认领）时才准备移动；`shell/title_tests.rs` 核对晃动的按下点得动 Linux 的关闭、标题栏空处照样移动窗口（去掉修复时前者失败）。未在真 Linux 桌面上点过。
 - 2026-10-11（用户报：ElyTree 改动列表里文件名长时盖住行尾的打开按钮）：组件库 bd01470：`ChangesList` 行里的文件名原为不缩的盒子，长名越过行宽压在按钮下；现可缩、以省略号结尾，先于按钮让位；`git/tests/narrow.rs` 核对 260 宽时文件名止于按钮之前（原布局时失败）。