Roblox 功能归属不清…

适用于 Roblox 项目中代码所有权不清、功能跨客户端/服务器、启动顺序重要或模块需要拆分的场景。

适用场景

解决思路

1. 为每个行为明确一个所有者，并列出：权威状态及谁可以修改它；公共操作及调用方；它拥有的 Roblox 实例、连接和任务；持久化或网络边界；启动与拆除条件。
2. 当按功能分组能让同一变更保持在一起时，按功能分组；仅在运行时边界要求的地方拆分服务器、客户端和共享代码。
3. 共享代码中不放置秘密或权威可变状态，因为被复制的代码可被客户端读取。
4. 稳定依赖默认使用直接模块调用；当一个发布者确实有互相独立的观察者时使用 signal。
5. 不要添加全局事件总线、依赖容器、manager class 或 `Init`/`Start` 仪式来隐藏普通依赖。
6. 保持模块顶层工作廉价且不 yielding；小型 bootstrap 只负责真正需要排序的启动。
7. 按顺序调用有序启动，并让失败可见；并发必须显式且安全，不要对每个模块自动 `task.spawn`。
8. 当依赖通过 replication 到达时，对 `WaitForChild` 设置边界并处理超时；无界等待会把缺失实例变成静默启动挂起。
9. 强制运行时权威：客户端提交输入和预测，服务器验证并决定权威结果。
10. 把 Remotes 当作 API，定义类型、边界、状态、所有权、滥用控制和失败行为；实现细节交由 `roblox-networking` 和 `roblox-security`。
11. 仅在有以下证据时拆分：独立生命周期或权威边界、独立持久化契约、可独立测试的纯核心、或无关的变更原因。
12. 不要为了文件夹对称或投机性复用而拆分。
13. 审查时确保：每次变更只有一个规范所有者；没有隐藏的启动 yield 或复制信任决策；显式清理；结构最小且可追踪。
14. 对于 tag-driven 行为，用 tags 做发现、attributes 做配置，并让一个所有者负责 attach/remove 清理。
15. 需要详细布局、依赖规则和启动示例时，查看 `references/full.md`。

适用边界 · 注意事项

• 小型功能不要仅仅为了引入 service/controller 框架而使用这套架构。
• 没有独立生命周期、权威边界、持久化契约、可独立测试纯核心或无关变更理由时，不要拆分。
• 普通稳定依赖不要用全局事件总线、依赖容器、manager class 或 `Init`/`Start` 仪式来隐藏。