[Windows][P1] 主窗口四周圆角与自绘外框贴合不完整

[Cooper-X-Oak]

治理归属

• 族群：A 族群 / 窗口外观契约
• canonical PR：fix(windows): 修复自绘窗口圆角与外框贴合 #125
• 主修范围：主窗口圆角、外框、titlebar、shadow、首帧 shell 贴合
• 不默认并入：capsule geometry、helper-window 生命周期、QA 语义、双热键事件源
• 参考：
  • docs/windows-window-governance-board.zh-CN.md
  • docs/2026-05-02-window-capability-family-audit.md
  • docs/github-tracking/windows-window-family-canonical-map.md

现象

Windows 主窗口已经比早期版本明显改善，但在 upstream/main 上四周圆角和外框仍然没有完全贴合：窗口外层圆角、内容壳圆角、边框 / shadow 的边界在视觉上还有轻微错位，尤其四角更容易看出不一致。

这不是“边缘 resize 不可用”的问题。人工复核 upstream 构建时，边缘拖拽 resize 可以工作；当前需要继续推进的是自绘窗口壳的视觉边界贴合，以及 first paint 时窗口形态与最终设计态的一致性。

静态证据 / Static evidence

• openless-all/app/src-tauri/tauri.conf.json 仍让主窗口以 decorations: true、visible: true 创建。
• openless-all/app/src-tauri/src/lib.rs Windows 路径会再叠加 Mica，并曾在运行时切换 decorations。
• openless-all/app/src/components/WindowChrome.tsx Windows 分支已经采用应用内自绘 titlebar / content shell。
• 当前圆角贴合依赖 WebView 内容壳、窗口 native frame、border / shadow 多层共同表现，Windows 下容易出现四角不完全重合。

运行证据 / Runtime evidence

• 基线：origin/main b7fda0d（Merge pull request docs: 新增火山 ASR 极简配置指南 #126）。
• 已在 Windows GNU release no-bundle 产物上复核 upstream/main。
• 用户人工测试确认边缘 resize 本身没有明显问题。
• 剩余可见问题集中在四周圆角 / 外框贴合不完美，以及 startup first-paint 与 final chrome 的轻微错位感。

与 macOS 原始设计意图的偏差 / Deviation from macOS design intent

• macOS 路径的原始意图更接近“窗口从 first paint 起就是最终设计态”，系统 titlebar / vibrancy 与应用内容层各司其职。
• Windows 当前却仍然存在“创建态”和“最终态”分离：前端 design intent 已经是 custom chrome，但 Tauri creation phase 仍沿用 native decorated window，再在 runtime 叠加调整。
• 偏差不在业务内容，而在 window shell contract 没有从创建时就稳定收敛。

5 Whys / 根因分析

1. 为什么主窗口四周圆角与外框还会不完全贴合？
   • 因为 native window、custom chrome、border / shadow 仍然不是一个在 first paint 就统一的几何边界。
2. 为什么 first paint 没有统一边界？
   • 因为窗口创建阶段和运行时阶段对 Windows chrome 的定义不完全一致。
3. 为什么会出现这种阶段错位？
   • 因为 Tauri window config、runtime window control、frontend WindowChrome 分散演进，没有 single source of truth。
4. 为什么这会偏离 macOS 设计意图？
   • 因为 macOS 更接近“创建即最终视觉态”，而 Windows 当前允许 first paint 落在过渡态。
5. 为什么这个问题在 Windows 上更显性？
   • 因为 DWM / Mica / frameless lifecycle 差异，让“先创建再改外壳”的策略更容易变成用户可见的圆角和边框错位。

平台边界 / Platform scope

• 直接症状范围：当前是 Windows-only symptom。
• 问题层面：window config / runtime shell control / frontend chrome contract。
• 全平台风险判断：根因模式有 cross-platform risk，只是 Windows 最先显性暴露。

影响

• 主窗口四角会显得像“壳”和“内容”没有完全对齐，影响 Windows 桌面端完成度。
• 如果后续继续调整 custom chrome，需要避免把视觉修复变成 resize / titlebar 交互回归。
• 这个问题也会放大 cold-start UI 不稳定感，但它本身首先发生在 window shell layer，而不是业务页面层。

建议接受标准

• Windows 主窗口四个角的 native window、WebView 内容层、border / shadow 视觉上贴合。
• 100% / 125% DPI 下四角不出现明显漏底、错位、双层圆角或硬边。
• 边缘 resize、最小化、最大化、关闭等窗口交互保持可用。
• macOS 仍保留系统红黄绿窗口控制，不因 Windows 修复回归。
• issue 生命周期继续由 Draft PR fix(windows): 修复自绘窗口圆角与外框贴合 #125 承接并在 merge 时闭环。

关联修复

Draft PR：#125

TODO / 不确定项

• 是否要把“first visible frame == final chrome”写成 Windows 主窗口的显式验收门禁。
• 需要补一次 Windows 11 实机人工复核，确认 DWM / WebView2 版本差异不会导致边角个案。

[Cooper-X-Oak]

设计治理关联 / Governance link: #158。该票属于跨平台 helper-window / native-window contract 族群案例之一，后续可在 #158 下统一沉淀设计经验与平台边界。

[Cooper-X-Oak]

Family mapping note:

This issue is now treated as the canonical anchor for Family A: Window Shell Appearance.

Owned scope:

• main window round corner / outer frame / titlebar / shell fit
• first visible shell consistency when it is directly part of appearance correctness
• frameless resize affordance only when it is required to keep the shell contract usable

Do not merge into this issue by default:

• helper-window lifecycle participation
• QA helper-window semantics
• dual hotkey source ownership
• capsule geometry-only distortion topics

Reference docs:

• docs/2026-05-02-window-capability-family-audit.md
• docs/github-tracking/windows-window-family-canonical-map.md