Tauri desktop app

Tauri desktop app 指 Rust 原生侧与 Web UI 前端通过 Tauri 组成同一个桌面产品，二者共同构成交付面。它不是单纯“桌面端套个网页壳”，而是要长期维护 Rust 系统能力、前端交互层、桌面打包和两侧桥接 API 的工程模式（projects/display-ambient-light-desktop.md）。

它和 Rust application、TypeScript web、UI version display 相邻，但重点不同：Rust application 讲应用交付，TypeScript web 讲前端栈，Tauri desktop app 讲的是这两层通过 Tauri 绑在一起后产生的新边界和维护习惯。

当仓库存在 src-tauri/ 与前端 src/ 双结构，且改动会影响 Tauri command/API、原生设备访问、本地 HTTP/info endpoint、桌面打包、前端构建集成、窗口壳层或前后端版本同步时使用。凡是问题不能只靠纯前端或纯 Rust 一侧解释，就很可能命中本 Topic。

如果项目只是 Electron、普通 Web app，或 Rust 仅作为辅助脚本存在，不应贴成 Tauri desktop app。这个 Topic 要求 Tauri 是正式产品边界，而不是试验性包装。

• 保持 src-tauri/ 与前端源码的清晰边界。原生层负责设备访问、系统集成、桌面能力和稳定 API；前端层负责展示、交互和状态组织。两者通过少量明确命令或本地 API 接缝通信，而不是互相渗透。
• Tauri 项目通常要同时固定 Rust 与前端 toolchain。只要其中一侧版本漂移，桌面壳层就可能从“可构建”变成“本地环境限定可构建”，因此 pinned toolchain 是常见默认值。
• 版本显示和诊断入口应跨过前后端边界保持一致。像 projects/display-ambient-light-desktop.md 这样从原生侧提供 info/version，再由 About UI 消费，能避免前端单独读到一个与实际桌面产物脱节的版本号。
• 桌面应用的本地验证至少要覆盖启动、前后端握手、核心原生能力调用和一个真实 UI 路径。单独跑前端 build 或 Rust test 都不足以证明 Tauri 产品可用。
• 原生侧接口一旦对前端开放，就要把它们当 API contract 来审查。随手改 command 名称、payload 结构或本地 HTTP 路由，是 Tauri 项目里最常见的破坏性改动来源。

• projects/display-ambient-light-desktop.md：当前核心样本。它清楚展示了 src-tauri/、前端 src/、toolchain pinning 和 About/version path 如何共同构成一个可维护的 Tauri 桌面产品。
• skills/style-tauri-desktop-app/SKILL.md：group Skill 强化了消费侧关注点：遇到这类项目，后续 Agent 应主动核对前后端边界、原生接口和桌面打包，而不是只把它当成“又一个前端应用”。

• 只把 Tauri 当打包器使用，不维护前后端之间的稳定接口，会导致原生能力与 UI 状态不断脱节。
• 前端和 Rust 两侧各自单独报版本、单独管理状态，最终会出现用户看到的版本、日志里的版本和实际桌面产物不一致。
• 仅验证 Web UI，不验证桌面启动与原生能力调用，会让大量 Tauri 特有问题在最后阶段才暴露。
• 原生侧随意暴露过多 command 或本地 API，久而久之会把前端直接耦死在桌面实现细节上，丧失后续替换或重构空间。

• projects/display-ambient-light-desktop.md
• skills/style-tauri-desktop-app/SKILL.md
• skills/style-playbook/references/data/topics/tauri-desktop-app.json