Rust application

Rust application 指 Rust 是主执行面之一，交付物直接面向终端用户或操作者，而不是仅作为库、后端服务或固件组件存在。这里关心的是“应用如何被构建、运行、打包、调试和支撑用户工作流”，包括桌面 app、带 Web UI 的 hybrid app，或强用户导向的本地工具（projects/display-ambient-light-desktop.md、projects/televy-backup.md）。

它和 Rust web service、Tauri desktop app、macOS app 的区别在于粒度。Rust application 先回答“这个仓库的主产品是不是 Rust 应用”，再由相邻 Topic 细分是服务、Tauri 还是 macOS 平台。

当仓库的主 artifact 是用户要直接运行和感知的应用，且改动会影响启动入口、打包/分发、用户配置、本地状态、前后端混合边界、toolchain pinning 或跨平台运行行为时使用。对 hybrid desktop app 来说，只要 Rust 侧不只是附带 helper，而是承担正式产品能力，就应该命中本 Topic。

若仓库只是 Rust 库、服务端组件、嵌入式 crate 或某个测试工具，不应贴成 Rust application。这里要强调的是“以应用交付为中心的 Rust 维护习惯”。

• 应用入口、构建路径和用户可见版本信息应尽量稳定且脚本化。对用户应用来说，“怎么运行”“产物长什么样”“如何确认版本”都是正式 contract，不该散落在维护者记忆里。
• 当 Rust 与 Web UI 混合时，边界要清楚：Rust 负责哪些本地能力、状态或系统集成，前端负责哪些交互和展示。像 projects/display-ambient-light-desktop.md 这种 src/ 与 src-tauri/ 分层，就比把所有逻辑揉在一层里更可维护。
• Toolchain pinning 往往比服务端项目更重要，因为应用构建常跨越前端、Rust、平台 SDK 和打包链。若不固定版本，用户 app 最先遭遇的是“别人机器上能打，我这里不能打”。
• 质量门禁不该只盯编译成功，还要覆盖至少一个真实运行路径。应用项目里，能 build 不等于能启动、能展示正确状态、能和本地系统能力正常协作。
• Packaging 和 release 材料是应用本体的一部分。只维护源码、不维护打包入口，会让仓库慢慢退化成只能本地开发、无法交付的半成品。

• projects/display-ambient-light-desktop.md：代表 Rust + Web UI 的 hybrid application 形态，适合说明本 Topic 为什么既要看 Rust toolchain，也要看前端壳层与版本显示。
• projects/televy-backup.md：代表更偏平台桌面应用的一侧，说明 workspace、macOS build scripts 和 packaging 怎样一起构成应用交付面。
• skills/style-rust-application/SKILL.md：group Skill 证明后续 Agent 消费这个 Topic 时，应该回到应用入口、打包和用户运行路径，而不是停留在“这是个 Rust 仓库”。

• 把所有 Rust repo 都贴成 Rust application，会让这个 Topic 失去筛选价值。没有用户交付面的库或服务，应回到更具体的 Topic。
• 只关注 crate 架构，不关注应用运行/打包路径，会让文档看似专业，实际却回答不了“怎么把产品交付给人用”。
• 混合应用若不明确前后端边界，问题一出现就难以判断该查 Tauri/Rust、前端构建，还是平台环境。
• 只跑 CI build、不做真实启动验证，会反复产生“二进制打出来了，但应用不可用”的假绿。

• projects/display-ambient-light-desktop.md
• projects/televy-backup.md
• skills/style-rust-application/SKILL.md
• skills/style-playbook/references/data/topics/rust-application.json