放置规则

新增能力进入哪个层级，取决于它是否必须被内核识别、是否足够基础、是否可选、是否属于运行时能力，以及是否包含项目语义。

基础规则

• 框架启动、生命周期、注册、事件、绑定、插件入口：放 kernel。
• 需要 kernel 直接识别的协议、基类、类型关系工具和诊断结构：放 kernel。
• 纯算法、纯数据、通用输入、通用运行时服务、状态机等稳定标准能力：放 standard。
• 战斗、网络、存档、流程图、能力、交互、行为树、领域模型等可选但通用的内置能力：放 addons/gf/extensions/<name>。
• 导入、生成、烘焙、迁移、发布、审计、编辑器工作流等只在制作期使用的能力：放工具包或 addons/gf 外的独立插件，不能让运行时包反向依赖这些工具。
• SDK、地形生成器、画笔、跨扩展组合、项目适配、业务偏强工具：放项目代码或 addons/gf 外的独立插件。

判断顺序

当一个新能力难以归类时，先问它是否必须被 kernel 直接引用。如果是，抽出最小内核契约放入 kernel，具体实现仍可在 standard 或扩展中。

若不是，再问它是否足够基础到所有项目都应默认理解。如果答案是否定的，不进 standard。

最后判断它是否足够通用、抽象、可独立启用，适合成为 GF 内置扩展。跨扩展组合和项目语义始终留在项目层或独立插件中。

运行时与工具

extension 表示玩家运行游戏时可能需要的可选能力。tool 表示开发者、策划或 CI 在制作、导入、生成、烘焙、检查和发布时使用的能力。工具可以依赖它服务的运行时包，运行时包不能依赖工具。

例如：

gf.standard.config <- gf.tool.config_pipeline
gf.extension.terrain <- gf.tool.terrain_editor
gf.kernel <- gf.tool.package_audit

安装 gf.tool.config_pipeline 时，可以同时安装它需要的 gf.standard.config 等运行时依赖；安装 gf.standard.config 时，不应自动安装导表工具。项目导出游戏时，工具包也不应进入默认运行时闭包。

如果某个扩展只有少量 Inspector、按钮或简单编辑器增强，可以放在该扩展自己的 editor/ 目录中。若能力已经变成导入器、代码生成器、批量烘焙、发布检查或外部命令包装，应拆成工具包或独立插件。