放置、Godot 边界与测试¶
新增能力应先判断归属层级。GF 代码边界和 Godot 引擎边界都要保持清楚，测试优先覆盖纯逻辑和模块协作。
归属判断¶
新增能力时先判断它属于哪一层：
- 框架启动、注册、事件、绑定、扩展基础设施：
kernel。 - 纯算法、纯值对象、格式化、校验和通用数据结构：
standard/foundation。 - 需要生命周期、缓存、异步、ProjectSettings 或全局状态的通用服务：
standard/utilities。 - 可选、通用、可独立启用的能力：
addons/gf/extensions/<name>。 - 具体业务规则、跨扩展组合和项目适配：项目代码或
addons/gf外的独立插件。
不要为了复用方便把项目规则写回 GF 内置扩展。内置扩展应保持原子化，跨扩展组合由项目 Installer 或独立插件负责。
Godot 边界¶
Godot 物理、输入、渲染和场景树生命周期以引擎为准。GF 负责组织代码边界，不接管引擎语义。
例如物理移动、碰撞响应和角色控制仍应遵循 Godot 的 _physics_process()、CharacterBody、Area、RigidBody 等规则。GF 可以提供状态、配置和流程协调，但不应让 System 直接替代引擎节点执行物理细节。
测试¶
优先测试纯逻辑和模块边界：
- Model 的状态变化和快照恢复。
- System 对事件、命令、查询和依赖缺失的处理。
- Utility 的异步、缓存、错误报告和释放语义。
- Controller 只做薄桥接时，使用少量场景测试覆盖关键连接。
框架级变更应运行维护测试；项目级变更至少覆盖受影响模块的 GUT 测试。