这篇长文可以看作当前 Odroe 项目入口 的组合级补充。
如果你想先看更聚焦的项目说明，了解为什么现在会先从 Spry 讲起，可以继续阅读 Spry 是我当前 Dart 开源工作的中心。
需要英文版？阅读 English version。
为什么这件事值得单独写一篇
如果你现在打开 Odroe，会同时看到两类东西：
- 代表当前公开方向的项目；
- 仍然保留在站点里的历史 package 参考文档。
这个分层不是偶然出现的，而是刻意为之。
这些年我做过不少开源仓库、package 和实验项目。如果把它们继续并列摆在同一层，外部用户就很容易把“还在站点里”误读成“现在仍是重点”。
所以当前的 Odroe 入口遵循一个更简单的规则：
- 先把现在最重要的项目放到前面；
- 仍然让有参考价值的历史文档保持可读，但不再假装它们都在同一条主线上。
当前公开主线，用一句话怎么理解
现在理解 Odroe 当前项目组合，最直接的方式是：
Spry是框架主线，也是大多数人最应该先进入的项目。alien-signals-dart是响应式核心主线。oref是这条响应式方向在 Flutter 侧的表达。
它们不是为了“凑三个项目”才并排放在一起。
它们共同说明了 Odroe 当前正在公开构建什么：实用的开发者工具、响应式基础能力，以及可以继续延展出文档、starter、示例和 AI 辅助工作流的框架方向。
应该从哪里开始，看你想解决什么问题
最好的入口并不完全相同，而是取决于你想先评估哪一块。
如果你想先看框架主线，从 Spry 开始
如果你关注的是下面这些事情，就先看 Spry：
- 基于文件路由的 Dart 服务端工具链；
- 同一套代码跨多个运行时发布；
- 生成结果保持显式，而不是变成黑盒；
- 从同一个项目中产出 OpenAPI 文档与类型化客户端。
它之所以是当前最清晰的第一入口，不只是因为它是框架，也因为它拥有最强的产品表面积、文档杠杆和后续叙事延展空间。
如果你更关心响应式核心，从 Alien Signals 开始
如果你更关心下面这些事情，就先看 alien-signals-dart：
- 面向 Dart 与 Flutter 的轻量响应式原语；
- signals 风格的状态与派生模型；
- 更偏底层、而不是一整套大框架的能力。
这里承接的是更紧凑、更技术向的响应式主线。
如果你更关心 Flutter 侧体验，从 Oref 开始
如果你更关心下面这些事情，就先看 oref：
- 在 Flutter 中使用更顺手的响应式开发体验；
- 把 signals 风格的思路落进真实应用代码；
- 理解响应式核心如何变成更实用的开发者体验。
oref 的价值在于，它让当前组合不至于收缩成纯服务端叙事，也让同一套偏好在 Flutter 场景里有了更具体的落点。
为什么旧 package 文档还会继续保留
有些较早的 package 页面还会继续保留在 odroe.dev 上，因为它们仍然有参考价值。
但“仍然可读”并不等于“仍然是当前旗舰项目”。
这里的规则很直接：
- 当前项目决定公开入口的主视觉和主叙事；
- 参考项目继续保留文档，但不再争夺同样的顶层注意力。
这也是为什么 Oinject、Once Call 这类页面还在，但它们现在会被明确呈现成参考文档，而不是当前主线的一部分。
Odroe 这个入口到底在做什么
Odroe 不应该只是一个随手堆仓库链接的目录。
它应该帮助用户更快回答四个问题：
- 现在正在做什么？
- 现阶段最值得先看哪些项目？
- 什么是当前主线，什么只是参考保留？
- 下一步应该点去哪里？
也正因为如此，核心项目并不需要全部都放在同一个 GitHub 组织名下，才能形成一条对外连贯的公开主线。真正重要的是，用户先从 Odroe 进入，再被正确分流到当前最合适的项目入口。
如果你想继续往下跟
不同渠道对应不同深度：
- 用 首页 获取最短的品牌与项目入口；
- 用 /zh/packages 查看项目组合层面的分层；
- 用 Spry 是我当前 Dart 开源工作的中心 理解当前重心为什么会落在这里；
- 关注 @OdroeDev 获取更短的公开更新；
- 用 Medium 跟进同步分发的长文。
核心意思其实很简单：
Odroe 的任务，是让人更快理解当前项目组合，而不是让人从一串平铺的仓库里自己猜主线。