Rust workspace

Rust workspace 指仓库通过 multi-crate workspace 明确拆出 domain、daemon、CLI、平台壳层或共享库边界，并把这种拆分当成长期维护契约，而不是一时为了方便 cargo 命令。这里关注的是 crate 之间的职责分工、共享代码如何流动、哪些能力应该被隔离，以及 workspace 结构怎样支撑后续测试、打包和演进（projects/televy-backup.md）。

它和 Rust application、Rust web service 相邻，但更底层。那些 Topic 先回答交付物是什么；Rust workspace 回答的是“为了支撑这种交付，Rust 代码被怎样拆层”。

当仓库的 Cargo.toml 定义正式 workspace，且改动会影响 crate 边界、members/exclude、共享依赖、公共 API、daemon/core/cli 分层、feature 传播或打包时使用。尤其当不同产物共享核心逻辑、但又需要隔离平台代码或运行态责任时，这个 Topic 很关键。

若项目只是单 crate，或目录上看起来很多但没有通过 workspace 管理成稳定边界，则不应命中。这里讨论的是架构分层，而不是文件树数量。

• 每个 crate 都应有清晰主语。core 放领域逻辑，daemon 放长驻/系统集成，cli 放交互入口，平台壳层单独存在；不要让 workspace 只是“多个 crate 互相随便引用”的松散集合。
• 共享逻辑优先往内收敛到稳定 crate，而不是从 app/daemon 反向互调。这样 GUI、CLI、后台服务才能围绕同一核心能力演进，而不会出现谁都能直接碰持久化或平台层的混乱结构。
• members 与 exclude 也属于架构声明。像 projects/televy-backup.md 中把 crates/mtproto-helper 排除在主 workspace 外，本身就是一种边界表达：不是所有目录都必须进入正式 build/test/release contract。
• Workspace 改动要连带考虑测试和打包路径。新增 crate、移动模块或提取公共库时，不能只让 cargo check 通过，还要看 build scripts、平台壳层和 release workflow 是否仍能找到正确入口。
• 让 crate 名称与目录职责保持一致，能显著降低后续 Agent 的理解成本。对 style playbook 来说，这类命名稳定性本身就是可复用的维护习惯。

• projects/televy-backup.md：当前核心样本。它把 core、daemon、cli、macOS app 和 packaging 一起维护，正好体现 workspace 为什么既是代码组织问题，也是交付边界问题。
• skills/style-rust-workspace/SKILL.md：group Skill 反向证明后续 Agent 应优先去看 crate 分工和共享边界，而不是把 workspace 仅仅当成 cargo 语法。

• 只因为有多个 crate 就打 Rust workspace，却不解释它们的职责分工，会让这个 Topic 变成目录结构描述，而不是工程模式。
• 把任何共享代码都随手塞进“common” crate，会让 workspace 逐渐变成耦合泥球，反而削弱边界。
• 改了 crate 结构却不更新脚本、release 入口和平台壳层，最常见结果是源码分层“更优雅”了，实际交付链路却断了。
• 若 core、daemon、cli 等边界没有明确文档和调用方向，后续维护者很快又会把业务逻辑拉回入口层。

• projects/televy-backup.md
• skills/style-rust-workspace/SKILL.md
• skills/style-playbook/references/data/topics/rust-workspace.json