diff --git a/GFramework.Game.SourceGenerators/README.md b/GFramework.Game.SourceGenerators/README.md
index 63478af8..1be51b44 100644
--- a/GFramework.Game.SourceGenerators/README.md
+++ b/GFramework.Game.SourceGenerators/README.md
@@ -14,6 +14,9 @@
 - 对应的表包装类型
 - 与 `GFramework.Game.Config` 运行时协作的访问辅助代码
 
+这里要先明确一条采用边界：`GFramework.Game.SourceGenerators` 服务的是当前与 `GFramework.Game`
+Runtime 对齐的共享 schema 子集，而不是任意 `JSON Schema` 的全量实现。它的目标是让配置生成、运行时校验和工具链维持同一份可落地契约，而不是把所有 schema 组合能力都映射成生成类型。
+
 ## 包关系
 
 - 运行时：`GFramework.Game`
@@ -73,6 +76,15 @@ GameProject/
 - 你希望在编译期拿到强类型配置访问入口
 - 你希望运行时加载、schema 校验和编辑工具链共用同一份结构定义
 
+如果你的 schema 设计依赖下面这些场景，就不属于当前默认采用路径：
+
+- `oneOf`
+- `anyOf`
+- 非 `false` 的 `additionalProperties`
+- 其他依赖开放对象形状、联合分支或属性合并的复杂组合约束
+
+遇到这些情况时，建议先回到 [配置系统文档](../docs/zh-CN/game/config-system.md) 和原始 schema / YAML 设计本体，确认是否需要调整配置建模方式，而不是默认期待生成器直接支持完整 `JSON Schema` 语义。
+
 ## 对应文档
 
 - 配置系统：[配置系统文档](../docs/zh-CN/game/config-system.md)
diff --git a/docs/zh-CN/game/serialization.md b/docs/zh-CN/game/serialization.md
index 1d05fcb8..762a435c 100644
--- a/docs/zh-CN/game/serialization.md
+++ b/docs/zh-CN/game/serialization.md
@@ -148,11 +148,14 @@ var restored = serializer.Deserialize(json, data.GetType());
 
 如果你的目标是静态内容配置表，而不是运行时持久化对象，请改看 [配置系统](./config-system.md)。
 
+如果你在配置系统里进一步碰到更复杂的 schema shape，也要尽快回到配置系统主文档和 raw YAML / schema 本体继续设计。当前默认采用路径面向的是与 `GFramework.Game` Runtime 和 `Game.SourceGenerators` 对齐的共享 schema 子集，不是任意 `JSON Schema` 的全量支持。
+
 ## 当前边界
 
 - 当前公开默认实现只有 JSON，没有内建 MessagePack、Binary 或 ProtoBuf 实现
 - `JsonSerializer` 负责序列化，不负责对象版本迁移；版本迁移属于 `SettingsModel<TRepository>` 或 `SaveRepository<TSaveData>`
 - 序列化器共享后应视为只读配置对象，避免在运行期继续修改 settings / converters
+- 如果配置设计依赖 `oneOf`、`anyOf`、非 `false` 的 `additionalProperties`，或其他需要开放对象形状与联合分支的复杂约束，请直接按配置系统主文档回到 raw YAML / schema 方案处理，而不是把这些场景归到序列化层
 
 ## 继续阅读
 
diff --git a/docs/zh-CN/game/storage.md b/docs/zh-CN/game/storage.md
index 9d2997b6..7f5778c8 100644
--- a/docs/zh-CN/game/storage.md
+++ b/docs/zh-CN/game/storage.md
@@ -165,6 +165,8 @@ var cacheStorage = new ScopedStorage(rootStorage, "runtime-cache");
 - 业务层如果想保存设置，可继续阅读 [设置系统](./setting.md)
 - 业务层如果只是需要底层存储实现，才直接依赖 `IStorage`
 
+如果你是在“配置系统最终把内容保存到哪里”这个角度读到这里，需要先把边界分开：`IStorage` 负责运行时持久化，不负责定义配置 schema 的支持范围。配置工作流里只要开始出现更复杂的 schema shape，仍应先回到 [配置系统](./config-system.md) 和 raw YAML / schema 本体继续设计，再决定运行时是否需要额外存储落盘策略。
+
 ## 当前边界
 
 - `FileStorage` 已经会通过注入的 `ISerializer` 自动序列化对象；默认接法不需要先手工 `Serialize(...)` 再把字符串写回
@@ -172,6 +174,7 @@ var cacheStorage = new ScopedStorage(rootStorage, "runtime-cache");
 - `ScopedStorage` 只做 key 前缀，不做权限、事务或迁移控制
 - 锁粒度是“当前实例内的目标路径”，不是跨进程文件锁
 - 原子写入只覆盖单文件替换，不等于多文件事务
+- 如果配置建模依赖 `oneOf`、`anyOf`、非 `false` 的 `additionalProperties`，或其他超出当前共享 schema 子集的复杂组合约束，这不是 `IStorage` 层能放宽的限制；应直接回到配置系统主文档与 raw YAML / schema 设计处理
 
 ## 继续阅读