[windows] 主窗口圆角贴合与外框不完整

[Cooper-X-Oak]

现象

• 触发条件：Windows 主窗口冷启动、首次 show、从隐藏态恢复、以及首帧切入自绘 WindowChrome 时。
• 当前表现：主窗口四周圆角贴合不稳定，外框会出现先带 native chrome、再切成 custom chrome 的观感；用户侧可见为圆角不完整、边缘不连续、外框像被切过一次。
• 代码证据：
  • openless-all/app/src-tauri/tauri.conf.json 曾同时配置 decorations: true、transparent: true、visible: true。
  • openless-all/app/src-tauri/src/lib.rs 在 Windows 启动路径里又调用 apply_mica(&main, None)，并曾在运行时 set_decorations(false)。
  • openless-all/app/src/components/WindowChrome.tsx 已实现 Windows 自绘标题栏，说明 frontend design intent 是 custom chrome，但 Tauri creation phase 没有一次性遵守这个意图。
• 与 macOS 原始设计意图的偏差：
  • macOS 的原始设计更接近“窗口从 first paint 起就是最终设计态”。
  • Windows 当前却是“创建态”和“最终态”分离，先按 native decorated window 创建，再切换成 custom chrome，偏离了这一设计意图。
• 平台范围判断：
  • 直接症状是 Windows-only，因为触发点依赖 decorations、Mica、DWM shadow、frameless creation strategy。
  • 根因模式有 cross-platform risk，因为“窗口创建态与前端设计态不一致”本身是通用架构问题。
• 生命周期差异：
  • Windows 下 native window creation、DWM frame attachment、Mica 生效、React mount 并不是同一个时点。
  • macOS 的原生 titlebar / vibrancy 更接近“创建即最终形态”；同一套“先创建再改外壳”的策略在 Windows 上更容易暴露为可见缺陷。
• 5 Whys / 根因分析：
  • Why 1：为什么圆角和外框不完整？因为 Windows 主窗口首帧和稳定态用了两套不同的 chrome 定义。
  • Why 2：为什么会出现两套 chrome 定义？因为 tauri.conf.json 保留 native decorations，而 lib.rs 又在运行时切到 frameless 并叠加 Mica。
  • Why 3：为什么创建阶段和运行时阶段没有统一？因为 Tauri window config、runtime window control、frontend WindowChrome 是分散演进的，没有 single source of truth。
  • Why 4：为什么这会偏离 macOS 设计意图？因为 macOS 路径更接近“创建即最终视觉态”，Windows 路径却允许 first paint 先落在过渡态。
  • Why 5：为什么问题会在 Windows 上更显性？因为 Windows 的 DWM / Mica / frameless lifecycle 差异，让“先创建再改外壳”更容易变成用户可见缺陷。
• 当前认领：暂以 draft PR docs(windows): 跟踪主窗口圆角与外框问题 #144 占位承接；上游仓库暂不可直接把 Cooper-X-Oak 设为 assignee。

影响

• 用户影响：破坏 Windows 用户对主窗口稳定性的第一印象，属于 startup visual trust 问题。
• 工程影响：影响后续自绘标题栏、阴影、圆角、Mica 叠层的调试，因为窗口基线形态本身不稳定。
• 范围影响：会放大冷启动闪烁问题，让后续更难区分是 frame layer 问题还是 first-content-paint 问题。
• 平台影响：当前直接影响 Windows；但其根因属于“窗口创建态与设计态不一致”的通用治理问题，需要防止同类模式继续扩散到其他平台。

建议接受标准

• Windows 主窗口在创建阶段就确定为最终 chrome 策略，不再依赖创建后切 decorations。
• 首次 show 到稳定态之间，圆角、边框、阴影与自绘标题栏视觉连续。
• tauri.conf.json、src/lib.rs、WindowChrome.tsx 对 Windows 主窗口职责边界有清晰注释或约束。
• 验证至少包含 npm run build 与一次 Windows 主窗口冷启动 smoke。
• issue 生命周期由 draft PR docs(windows): 跟踪主窗口圆角与外框问题 #144 承接；仅当 PR 从 draft 转 ready 并最终 merge，才视为该 issue 完成。

TODO / 不确定项

• TODO：需要在 Windows 11 实机上补一轮肉眼 smoke，确认 DWM / WebView2 版本差异是否还会引入边缘个案。
• TODO：如果后续决定保留 native shadow，需要明确它属于 Tauri 创建参数还是 DWM 自动行为。
• TODO：cargo check --manifest-path openless-all/app/src-tauri/Cargo.toml 当前被仓库既有错误 openless-all/app/src-tauri/src/commands.rs:55 阻塞，阻塞点与本 issue 不同源。

[Cooper-X-Oak]

Duplicate of #127.\n\nThe additional Windows/macOS design-intent analysis, lifecycle notes, and 5 Whys have been merged back into the earlier issue #127, which remains the canonical tracker for this problem.

[Cooper-X-Oak]

Closing as duplicate of #127. Please continue discussion and eventual fix/merge lifecycle there.