优化结构

internal/data/README.md

@@ -15,7 +15,11 @@ feature can be found by its domain instead of by scanning one large package.
   persistence. Provider SDK implementations are separate in
   `internal/integration/payment`.
 - `internal/data/migration` contains the version-table runner used by the
-  root migration coordinator.
+  root migration coordinator. It stays under data because it executes and
+  records database schema steps.
+- `internal/adminsurface` contains the small menu/API metadata contract used
+  when a business module contributes pages to the administration UI. It lives
+  outside `data` because the contract itself is not persistence code.
 
 The root package intentionally keeps only cross-cutting infrastructure:
 database lifecycle/reloads, runtime configuration persistence, data-scope
@@ -23,6 +27,27 @@ auditing, integration configuration storage, and migration orchestration.
 Repositories depend on narrow module seams (`system.Provider` and
 `payment.Provider`) rather than importing the root implementation details.
 
+First-install and configuration-management orchestration lives in
+`internal/initialize`. It implements `biz.InitializationRepo` through a narrow
+backend interface that `*data.Data` satisfies. This keeps administrator/menu/API
+seeding out of the database lifecycle package while retaining one migration
+entry point.
+
 Non-database adapters remain under `internal/integration` (storage, email,
-payment SDKs, and cache), while reusable GORM and pagination helpers live in
-`pkg/gormkit` and `pkg/pagination`.
+payment SDKs, and cache). Their constructors are provided by
+`internal/integration.ProviderSet`, separate from the data provider set.
+GORM and pagination helpers live beside the data layer; stateless payment
+parsing lives in `internal/utils/paymentutil`; admin JWT handling lives in
+`internal/security/adminauth`.
+
+## Migration and bootstrap
+
+There is one migration execution entry point: `migrateAll` in the root data
+package. The root owns the shared integration-configuration table and appends
+the steps returned by `system.Migrations()` and `payment.Migrations()`.
+
+Migrations create schemas and module-required fixed records only. Initial
+business data is separate: `initialize.Repo` invokes `system.SeedSystem` only
+from the explicit first-install flow to create the administrator, roles,
+menus, APIs, departments, policies, and module-provided administration
+surfaces.