优化结构

docs/system-structure-audit.md

@@ -1,7 +1,7 @@
 # `internal` 目录结构优化结论
 
-参考 Go Kratos 的分层方式，顶层保留 `app`、`modules`、`biz`、`conf`、`data`、
-`initialize`、`integration`、`security`、`server`、`service`、`worker` 十个
+参考 Go Kratos 的分层方式，顶层保留 `app`、`modules`、`biz`、`config`、`global`、
+`data`、`initialize`、`integration`、`security`、`server`、`service`、`worker` 等
 稳定职责。目录不是越少越好：同一技术角色文件较多时，应在所属层下分组，避免
 一个目录堆积几十个文件。
 
@@ -9,11 +9,12 @@
 
 ```text
 internal/
-  app/                 # 运行时组合根
+  app/                 # 应用组合根
   modules/             # 静态 catalog 和模块定义
   modules/payment/     # payment 模块定义
   biz/                 # DO、usecase、repo interface
-  conf/                # 配置 proto/runtime
+  config/              # Viper 配置、快照和热更新
+  global/              # 进程级共享资源
   data/                # PO、repo、数据库和迁移
   initialize/          # 首次安装和配置编排
   integration/         # 外部 I/O provider
@@ -40,15 +41,15 @@ internal/
   独立边界时不继续拆分。
 - 删除只转发 `pkg/protoutil` 的 `utils/configutil`。
 
-## `internal/app` 为什么只保留运行时组合
+## `internal/app` 为什么只保留应用组合
 
 `modules/catalog.go` 是静态模块注册点，负责按依赖顺序汇总各模块
-`Definition()`；`app/runtime.go` 只负责任务注册和依赖注入后的运行时路由组合。
+`Definition()`；`app/runtime.go` 只负责任务注册和依赖注入后的路由组合。
 这样模块定义不再和应用组合逻辑混在一起，也不能误并入 `biz`、`service` 或
 `data`。
 
 Catalog 只能自动汇总静态模块贡献；新增模块若提供运行时路由或依赖型任务，仍需
-在 cmd/Wire 中显式注册，直到统一的 runtime contribution 协议落地。
+在 cmd/Wire 中显式注册。
 
 ## 其他目录审查