1lck · 1lck · Oct 1, 2026 · Sep 30, 2026 · Sep 30, 2026 · Oct 1, 2026
@@ -8,7 +8,7 @@
 的布局组件，不要在业务页面里重新拼一套拖动逻辑。拖动过程中要保证界面
 稳定、面板不会缩成不可用的尺寸，也不能因为鼠标移动就重建整个页面。
 macOS 和 Windows 可以用不同的 UI 技术实现，但用户看到的交互行为和基本
-约束必须一致。
+约束必须一致。Windows 分隔条使用无高亮的间隙和调整光标，macOS 保留原生风格高亮；这项视觉差异不改变尺寸与性能约束。
 
 ## 问题
 
@@ -32,8 +32,13 @@ macOS 和 Windows 可以用不同的 UI 技术实现，但用户看到的交互
   中，避免每次拖动都重新计算整个功能页面。
 - 为面板设置最小尺寸、最大尺寸和可用空间约束。窗口缩放、面板隐藏和
   面板恢复后，都不能产生负尺寸或布局溢出。
-- 交互应与现有 Git、编辑器和工具窗口保持一致，包括悬停/拖动高亮、
-  平台习惯的调整光标、帮助文本和无障碍标签。
+- 同一平台的分隔条交互应保持一致。Windows 工作台、文件导航和 Git Log 列边缘使用
+  无高亮间隙以及 `ew-resize` / `ns-resize` 光标，避免连续面板边界出现额外蓝色线条；
+  macOS 的 `SplitHandleView` 保留悬停/拖动高亮。两端仍须保留帮助文本、无障碍标签、
+  尺寸限制和拖动结束后持久化。不要为了视觉统一删除这些交互约束。
+- Windows Git Log 列宽复用 `utils/document-resize-session.ts`，每帧只写局部 CSS 变量，
+  结束或卸载时提交一次宽度并释放监听。列的最小和最大宽度限制后，空间不足通过
+  表格横向滚动处理，不挤掉提交说明。
 - 如果尺寸需要在重启后保留，只在拖动结束时通过现有布局持久化机制保存
   最终尺寸，不要在拖动过程中持续写入持久化存储。
 - Windows 编辑器标签栏的滚轮处理和活动标签可见性判断必须使用内层可滚动
@@ -78,6 +83,11 @@ macOS 和 Windows 可以用不同的 UI 技术实现，但用户看到的交互
 外框还包含固定操作按钮，其宽度不等于标签列表可视宽度。读取外框的滚动
 范围会漏掉内层溢出；因此保留外框用于拖动命中判断，滚动使用独立的内层引用。
 
+### 强制两端使用同一种分隔条高亮
+
+不采用。两端的窗口呈现方式不同，Windows 无描边面板依靠间隙和调整光标识别边界，
+macOS 继续使用既有原生风格。视觉差异仅限这些分隔条，不放宽生命周期、性能或可访问性约束。
+
 ## 后果
 
 - 收益：拖动行为更稳定，面板不会轻易出现负尺寸或溢出，页面重建范围更小。
@@ -94,7 +104,9 @@ macOS 和 Windows 可以用不同的 UI 技术实现，但用户看到的交互
 - Windows 标签滚轮行为测试：
   `cd windows/tauri && bun test src/features/tabs/hooks/use-tab-wheel-scroll.test.tsx`
   Windows CI 显式运行整个 `src/features/tabs` 测试目录，并生成逐项计时报告。
-- 代码审查时确认拖动不会导致高频整页重绘
+- Git Log 列宽、日期和布局测试由 Windows CI 的 Git Log 验证步骤运行并输出逐项计时报告。
+- 代码审查时确认拖动不会导致高频整页重绘；Windows 人工验证间隙无高亮、光标正确，
+  macOS 人工确认 `SplitHandleView` 高亮保持不变。
 
 ## 适用范围
 

@@ -374,6 +374,17 @@ Monaco 视图。语法 token 仍使用统一的 `color-mappings.json` 与共享
 Monaco 会给未指定背景的概览标尺填入默认分词背景色，在壁纸模式下形成黑色竖条；
 显式传入透明色后，概览标尺与编辑区一起露出工作台图片。
 
+中文输入法的组合输入（候选文字尚未确认的阶段）有一个例外：Monaco 会把
+当前行的一部分放入临时文本输入框，覆盖原来的代码行。Monaco 0.55.1 默认把
+当前行高亮色直接用作输入框底色，而原生配色的高亮只有 3.5% 不透明度，下面
+的字形就会透出并形成重影。macOS 的 `ime-input.css` 仅在组合输入期间把高亮、
+编辑器底色和不透明的主题浮层底色叠合，保证临时输入框遮住原文字。背景图模式
+也只在这个临时矩形内使用实体底色；结束组合输入后恢复原有透明输入框。
+不要通过隐藏输入框文字、改写候选输入事件或强制定时重绘来遮掩问题，否则会
+影响输入法反馈或输入状态。真实 Monaco 的组合事件测试验证明暗主题、有无壁纸
+及输入框退出后的样式恢复；原生输入法候选、删除和 WebKit 实际绘制仍需 macOS
+实机验证。
+
 ### 只读差异视图
 
 维护者验收后不接受 macOS 的 Monaco 默认 diff 外观，因此 macOS 历史记录、分支比较、
@@ -412,6 +423,46 @@ working-tree review 的显式身份，不回退到可能已经切换的工作区
 错误通过现有本地化提示呈现。纯逻辑回归覆盖稀疏分块、两种操作及这些生命周期边界，
 并纳入 Windows Git 随机顺序 CI；真实 WebView2 的按钮与 Git 状态联动仍需宿主验收。
 
+Windows 单文件工作区 Diff 还要能展开省略的未改动代码（#557）。稀疏补丁里根本
+没有这些行，所以“展开”无从谈起；之前强行关闭折叠，结果连展开按钮都不显示。
+现在单文件打开和刷新时请求整份文件作为上下文（`contextLines` 取 Git 接受的
+最大值 2147483647），结果标记为完整上下文（`is_full_context`），只有这种补丁
+才开启 Monaco 的未改动区域折叠。多文件、历史和提交比较仍用稀疏补丁且不折叠，
+因为它们缺少的行同样无法展示。
+
+Windows 工作区差异还能按块回滚（#688），与 macOS 的“Discard this change block”
+对齐。回滚按钮和暂存按钮放在同一个分块操作区，由共享渲染器的多 action 机制
+渲染，没有改动共享渲染器；分隔带上的箭头需要在两侧编辑器之间额外绘制并跟随
+Monaco 的对齐与折叠，收益不足以承担 macOS 对照入口的回归风险，暂不复刻。
+按钮回传的仍是原始分块身份，Windows 适配器取出同一份补丁，通过
+`git_discard_hunk` 翻译为 `git.apply` 的 `discard` 模式（`git apply --reverse`，
+只写工作区）。回滚只在满足以下条件时出现：未暂存的单文件 review、有工作区刷新
+目标、文件不是新增／删除／重命名／二进制，且 Git 状态里该文件没有已暂存改动。
+未暂存单文件 review 用的是 HEAD 到工作区的快照，若文件同时有暂存改动，
+补丁会包含暂存块，反向应用到工作区会失败或误删，所以这时只保留暂存按钮；
+刷新时按最新状态重新判断。多文件 review 没有刷新目标，回滚后旧补丁会留在
+屏幕上，因此也不提供。点击后先走现有“丢弃前确认”设置（`confirmBeforeDiscard`）
+的确认框；确认框打开期间同一份补丁拒绝其他操作，补丁在等待期间被刷新替换时，
+用户的回答直接作废。成功后照常等待 Git 变更事件刷新，最后一块回滚、文件
+不再出现在状态中时 review 关闭。Core 用真实仓库验证重建补丁（含完整上下文
+切出的分块）只恢复所选块、重复点击的旧补丁不写入、暂存区保持不变。
+
+这是受限的首版能力，不能视为所有工作区 Diff 都支持块级回滚。现有前端补丁解析
+会丢失行尾 `\r` 和文件末尾无换行标记：`core.autocrlf=false` 的 CRLF 文件，
+以及涉及末尾无换行的修改块，重建补丁可能被 Git 拒绝。拒绝时文件不变，用户只能
+退回文件级回滚；后续完善应保留原始补丁信息并覆盖暂存和回滚两条路径，不能通过
+忽略补丁错误或直接按显示行号改写文件来绕过校验。
+
+整份文件只有一个 `@@`，直接拿来暂存会把整个文件一次写进索引。因此 Windows
+适配器按 Git 默认的 3 行上下文重新切出分块，自己生成 `@@` 范围；单测用同一次
+修改的真实 `git diff` 输出逐块比对。完整上下文没有 `@@` 行，渲染器改用行上的
+`actionAnchor` 标记放置按钮，并按每一侧实际显示的行数计算位置，左右两侧保持对齐。
+
+Monaco 会把旧的折叠状态带到新内容上：挂载时的空模型没有未改动区域，第一份
+真实文本的所有区域都会被当作“已展开”。渲染器在文本被替换时重新挂接模型，
+让折叠状态从头计算；文本相同的刷新不重挂，读者已展开的区域保留。
+真实 WebKit 回归覆盖首次折叠、单个按钮和搜索揭示，去掉重挂会失败。
+
 预览借用主编辑器时还保存查找栏的查询、选项和显隐状态。关闭预览必须恢复
 主编辑器原先的查找状态，不能把替换预览的查询栏留在原文件中。
 

@@ -233,8 +233,41 @@ Maven、版本、路径和来源，例如「自动 → JDK 21.0.4 · 路径 ·
 版本比较。运行面板保留一步进入「设置 → 运行配置」并定位当前服务的入口；两端设置窗口
 每次分类请求都会重新定位，重复请求同一分类同样生效。
 
-「自动」本身的选择规则（是否按项目要求版本挑选、Windows 候选排序）属于 #815，不在此处
-改变。
+### 自动 JDK 选择（#815）
+
+自动模式先满足项目已有的 Java 最低版本要求，再按来源选择。显式选择的项目 JDK、
+服务 JDK 或 Maven JDK 不会被自动替换。两端共用 Core `runConfig.selectJava`，版本
+比较复用现有需求诊断中的逻辑，兼容 Java 8 的 `1.8` 表达；不要在 Swift/TypeScript
+各写一套版本比较，也不要重新解析 POM 或建立另一个项目模型。JDT LS 仍拥有语言
+服务项目状态，本次只消费既有生成文档中的最低版本，选择机器上的启动工具。
+
+来源顺序为 JAVA_HOME、PATH、普通安装、Windows 项目内安装。来源相同时先按数值
+版本降序，再按候选标识排序，避免目录枚举顺序左右结果。macOS 没有版本要求时
+保留原有 JAVA_HOME/首个发现候选回退；Windows 无要求时仍按来源选取，但修正原本
+覆盖 JAVA_HOME 优先级的字符串排序。没有任何兼容版本时继续保留回退选择，同时在
+生效值旁显示安装兼容 JDK 的提示。损坏或未来版本的需求文件明确报错，不按无要求处理。
+
+例如项目要求 Java 17、JAVA_HOME 为 8、PATH 为 17、普通目录有 21 时，自动选择
+PATH 的 17；显式选择 8 仍保留 8，由既有启动诊断报告不兼容。不要仅让设置页显示
+17，而启动仍取候选列表第一个 8。Windows 的发现结果也把实际自动候选放在首位，
+保证 Run 诊断与宿主启动一致。Windows 设置与服务表单在项目发现结果更新后重新解析
+生效值，即使自动路径字段仍为空；旧请求不能覆盖刷新后的结果。macOS 的 Run、Maven、
+测试和设置经过同一个选择入口。
+
+考虑过只改 Windows 排序，但这不能解决两端忽略项目要求的问题。也没有直接选最高
+版本：兼容的 JAVA_HOME/PATH 是用户已有环境意图，应优先保留。选择策略只读取现有
+工作区需求文档，不生成文件、探测进程或写入安装包。macOS 启动复用当前项目已经
+探测的候选；尚未完成完整发现时只探测 Java 并保留到项目切换或显式刷新，不能为了
+选择 Java 连带探测 Maven。无版本要求且 JAVA_HOME 可用时保留不探测的快速路径。
+PATH 仅用于识别已有候选的来源（平台负责解析符号链接），不额外扩大默认候选集合；代价是需求变化后需要重新解析
+选择，不能把上一次项目的结果缓存成全局默认值。
+
+回归验证使用共享 `automatic-java-selection.json`，覆盖枚举反序、数值补丁版本、
+旧版 Java 格式、兼容候选筛选、无要求/无匹配回退、空候选及损坏文档。macOS 的
+`automaticJavaUsesProjectMinimumAndPreservesExplicitSelections` 验证设置选择、Maven
+继承、显式覆盖与项目切换；Windows 的
+`automatic_java_selection_reads_requirement_changes_without_probing` 验证同一工作区
+需求变化和显式路径旁路。原生实机验收仍需覆盖 Run、Maven 目标和测试运行。
 
 ### Maven 设置页的检测边界（#844）