feat: 完成sys模块迁移，对齐PHP/Java框架

- 重构sys模块架构，严格按admin/api/core分层
- 对齐所有sys实体与数据库表结构
- 实现完整的adminapi控制器，匹配PHP/Java契约
- 修复依赖注入问题，确保服务正确注册
- 添加自动迁移工具和契约验证
- 完善多租户支持和审计功能
- 统一命名规范，与PHP业务逻辑保持一致

admin/docs/src/wwjcloud/ai/checklists.md

@@ -1,21 +0,0 @@
-## 执行检查清单（给智能体）
-
-### 开发前
-- [ ] 对齐 PHP 模块/接口/字段
-- [ ] 核对 DB 结构（表/字段/类型/索引）
-- [ ] 明确路由分端（/adminapi, /api）与守卫
-
-### 开发中
-- [ ] 目录分层到位（Controller/Application/Core/Infrastructure/Entities/DTO）
-- [ ] 实体字段与 DB 一致；配置表仅用 `value(JSON)`
-- [ ] Controller 只路由+DTO 校验；不写业务/不碰 ORM
-- [ ] Application 负责编排与事务；Core 写规则；Infra 实现仓储与适配
-- [ ] 管理端控制器接 `JwtAuthGuard + RolesGuard`
-- [ ] 启用必要 Pipes（JSON/Timestamp）
-- [ ] 用例完成发布事件；耗时逻辑入队
-
-### 开发后
-- [ ] `npm run build` 通过（无类型警告）
-- [ ] 单测/集成/e2e 通过；关键路径有覆盖
-- [ ] Swagger 注解完整
-- [ ] 变更清单与迁移说明 

admin/docs/src/wwjcloud/ai/integration.md

@@ -1,154 +0,0 @@
-## 基础能力集成（Kafka / Redis / 队列 / 事务）
-
-### 总览
-- 目标: 将事件、任务、缓存、事务能力以统一规范接入 App/Core/Infrastructure 三层，替代“散落式调用”。
-- 约束: 由 Application 发起流程；Core 编排业务规则且不直接依赖外设；Infrastructure 提供具体实现。
-
-### 1) 事务（TypeORM）
-- 发起层: Application（用例级事务边界）
-- 使用方式:
-```ts
-// application/xxx.app.service.ts
-constructor(private readonly dataSource: DataSource, private readonly core: XxxCoreService) {}
-
-async runUseCase(dto: Dto) {
-  return await this.dataSource.transaction(async (manager) => {
-    // 将 manager 注入到仓储实现（通过请求域注入或方法透传）
-    await this.core.handle(dto); // Core 内仅调用仓储接口
-  });
-}
-```
-- 规范:
-  - 事务只在 Application 层开启；Core 不直接操作事务对象
-  - 多仓储参与时基于同一 `EntityManager`
-
-### 2) 队列（Bull/BullMQ 或 DB 队列）
-- 发起层: Application（用例结束后入队）
-- 接入点: `UnifiedQueueService` 或具体 Provider（如 `BullQueueProvider`/`DatabaseQueueProvider`）
-```ts
-// application/xxx.app.service.ts
-constructor(private readonly queue: UnifiedQueueService) {}
-
-await this.queue.addJob('media', 'generateThumbnail', { attId }, { attempts: 3, delay: 0 });
-```
-- 处理器建议放置:
-  - `infrastructure/queues/xxx.processor.ts` 或独立消费模块
-- 规范:
-  - 入队数据为最小必要字段（ID/键）；大对象存储DB再查
-
-### 3) 事件（Kafka / DB Outbox）
-- 发起层: Application（领域事件在用例完成后发布）
-- 接入点: `DomainEventService`（绑定 `IEventBus`，默认 DB Outbox，可切 Kafka）
-```ts
-// application/xxx.app.service.ts
-constructor(private readonly events: DomainEventService) {}
-
-await this.events.publishEvent(
-  'system.settings.storage.updated',
-  String(siteId),
-  String(siteId),
-  { storageType },
-);
-```
-- 配置切换:
-  - 通过 `EventBusModule` 的 provider 切换 `DatabaseEventBusProvider` ⇄ `KafkaEventBusProvider`
-- 规范:
-  - 事件名格式: `domain.aggregate.action`
-  - 载荷仅含必要业务字段，带上 `tenantId/siteId`
-
-### 4) Redis（缓存/限流/幂等）
-- 发起层: Application（流程性控制）或 Infrastructure（技术性实现）
-- 接入点: `RedisProvider`（`vendor/redis`）
-- 常见场景:
-  - 读多写少配置缓存：`sys_config` 读取后短缓存
-  - 上传限流/防刷：基于 IP/UID 的计数器
-  - 幂等：`SETNX` + 过期控制
-
-### 5) 存储（本地/云）
-- 发起层: Application 调用 Core 规则后，委托 Infrastructure Provider 落地
-- 接入点: `infrastructure/providers/*` 或 `vendor/storage/*`（如 `LocalStorageAdapter`）
-- 规范:
-  - Provider 通过接口注入，便于切换 OSS/COS/Qiniu
-
-### 6) 在三层中的放置原则
-- Application: 事务、入队、发事件、协调多 Core 服务
-- Core: 纯业务规则/策略与仓储接口；不直接依赖 Kafka/Redis/队列
-- Infrastructure: 队列消费者、存储/HTTP/Redis 具体实现、TypeORM 仓储实现
-
-### 7) 示例：Upload 模块接入
-- 用例: 上传完成 → 入库附件 → 入队生成缩略图
-```ts
-// application/upload.app.service.ts
-await this.dataSource.transaction(async (manager) => {
-  const att = await this.core.validateAndPlan(fileMeta);
-  await this.attachmentRepo.withManager(manager).save(att);
-});
-await this.queue.addJob('media', 'generateThumbnail', { attId: att.id });
-```
-
-### 8) 示例：Settings.Storage 接入
-- 用例: 切换默认存储 → 写 `sys_config` → 发布事件 → 入队校验可用性
-```ts
-// application/storage-settings.app.service.ts
-await this.dataSource.transaction(async (manager) => {
-  await this.core.ensureExclusiveDefault(type);
-  await this.sysConfigRepo.withManager(manager).setValue(key, value);
-});
-await this.events.publishEvent('system.settings.storage.updated', String(siteId), String(siteId), { type });
-await this.queue.addJob('ops', 'validateStorage', { type, siteId });
-```
-
-### 9) 配置与健康
-- 配置在 `VendorModule`/`EventBusModule` 注入；通过 `ConfigService` 读取连接信息
-- 健康检查：将 Redis/队列/事件写入健康聚合输出 
-
-### 10) 方案B：vendor/storage 标准结构（平台外设）
-```
-vendor/storage/
-├── index.ts                     # 统一导出(接口、Token、模块、适配器)
-├── storage.module.ts            # 可配置模块(选择具体实现)
-├── tokens.ts                    # 注入Token常量(如 STORAGE_ADAPTER)
-├── interfaces/
-│   ├── storage-adapter.ts       # 适配器接口(平台标准)
-│   └── types.ts                 # 通用类型(上传结果、签名参数等)
-├── adapters/
-│   ├── local.adapter.ts         # 本地实现
-│   ├── aliyun-oss.adapter.ts    # 阿里云实现
-│   ├── qcloud-cos.adapter.ts    # 腾讯云实现
-│   └── qiniu.adapter.ts         # 七牛云实现
-├── providers/
-│   ├── storage.provider.ts      # 工厂: 按配置/站点解析适配器
-│   └── registry.ts              # 多实例注册表 Map<siteId, adapter> + TTL
-├── health/storage.health.ts     # 健康检查(各实现可选实现)
-├── config/schema.ts             # 配置Schema(必需项校验)
-└── __tests__/
-    ├── storage.contract.spec.ts # 契约测试(接口一致性)
-    └── adapters/*.spec.ts       # 各实现最小测试
-```
-
-- Token
-```ts
-export const STORAGE_ADAPTER = 'STORAGE_ADAPTER';
-```
-- 接口
-```ts
-export interface StorageAdapter {
-  upload(params: { key: string; content: Buffer | NodeJS.ReadableStream; mime?: string }): Promise<{ url: string; key: string }>;
-  delete(key: string): Promise<void>;
-  signUpload?(params: { key: string; expiresSec?: number; mime?: string }): Promise<{ url: string; headers?: Record<string,string>; fields?: Record<string,string> }>;
-  healthCheck?(): Promise<boolean>;
-}
-```
-- 按 site_id 解析（站点启用 > 跟随系统 > local 兜底）
-```ts
-function resolveAdapter(siteId: number): StorageAdapter {
-  const enabled = readSiteEnabled(siteId);      // storage_xxx with is_use
-  const type = enabled?.type ?? readPlatformDefault();
-  const options = enabled?.options ?? readPlatformOptions(type) ?? {};
-  return registry.getOrCreate(siteId, type, options);
-}
-```
-- 本地隔离路径：`upload/site_{siteId}/...`
-- 健康检查：对活跃站点适配器定期 `healthCheck()` 并聚合到 Health
-
-> 说明：方案B 将“三方存储”视为外设，接口与实现均在 vendor；业务通过 Token 注入与按站点解析工厂使用，core 无需暴露存储端口。 

admin/docs/src/wwjcloud/ai/mapping.md

@@ -1,98 +0,0 @@
-## 模块关系映射（PHP ↔ NestJS）
-
-### 1) 职责映射总览
-
-| 职责 | PHP（ThinkPHP风格） | NestJS（规范分层） | 备注 |
-|---|---|---|---|
-| 控制器 | `app/admin/controller/*`、`app/api/controller/*` | `controllers/adminapi/*`、`controllers/api/*` | 仅路由与DTO校验（Nest特有：Guards/Pipes/Interceptors） |
-| 用例编排/流程 | `app/*/service/*`（可分 admin/api） | `application/*`（可分 `AdminXxxAppService`/`ApiXxxAppService`） | 事务、聚合领域规则、发事件/入队 |
-| 通用业务规则 | `core/*` 或被两端复用的 service | `core/services/*` | 不依赖外设（DDD） |
-| 仓储接口 | 与模型耦合在一起 | `domain/repositories/*` | 定义端口（接口） |
-| 仓储实现 | 模型(Model)直连DB | `infrastructure/repositories/*.typeorm.repository.ts` | TypeORM 实现，注入接口 |
-| 实体/模型 | `app/*/model/*` | `entities/*`（TypeORM 实体） | 字段与DB 100%一致 |
-| 外部适配 | SDK/Driver 封装 | `infrastructure/providers/*` 或 `vendor/*` | 存储/HTTP/SMS等 |
-| 配置中心 | `sys_config` + 配置文件 | `settings/*` 统一读写 `sys_config.value(JSON)` | 禁止 `config_value`、`app_type` |
-
-### 2) 目录映射（标准化）
-```
-your-module/
-├── your-module.module.ts                  # 模块定义（Nest特有）
-├── controllers/
-│   ├── adminapi/                          # 后台控制器（/adminapi）
-│   └── api/                               # 前台控制器（/api）
-├── application/                           # 用例编排（admin/api可分）
-├── core/
-│   ├── services/                          # 通用规则/策略（≈ PHP core）
-│   ├── repositories/                      # 仓储接口（端口）
-│   └── models|policies/                   # 值对象/策略（可选）
-├── infrastructure/
-│   ├── repositories/                      # TypeORM 实现
-│   └── providers/                         # 外部系统适配
-├── entities/                              # TypeORM实体（DB一致）
-└── dto/                                   # DTO（class-validator）
-```
-
-### 3) 命名映射规则
-- 应用层：`XxxAppService`（如 `AdminUploadAppService` / `ApiUploadAppService`）
-- Core层：`XxxCoreService`
-- 仓储接口：`XxxRepository`
-- 仓储实现：`XxxTypeormRepository`
-- 控制器：`XxxController`（位于 `controllers/adminapi|api`）
-- 配置键：常量化，如 `UPLOAD_CONFIG_KEY = 'upload'`，`STORAGE_LOCAL_KEY = 'storage_local'`
-
-### 4) 映射示例：Upload 模块
-- PHP 心智：
-  - admin/api 控制器 → 上传服务 → 模型写库（附件表）
-- NestJS 对应：
-  - 控制器：`controllers/adminapi/upload.controller.ts`、`controllers/api/upload.controller.ts`
-  - 应用：`application/upload.app.service.ts`（编排上传 → 领域校验 → Provider 落地 → 入库）
-  - Core：`core/services/upload.core.service.ts`（类型/大小/命名/路径策略）
-  - 仓储接口：`core/repositories/attachment.repository.ts`
-  - 仓储实现：`infrastructure/repositories/attachment.typeorm.repository.ts`
-  - 实体：`entities/sys-attachment.entity.ts`（严格对齐 `sys_attachment`）
-  - 适配：`infrastructure/providers/local.storage.provider.ts`（或 `vendor/storage/*`）
-
-流程：Controller → AppService（事务/编排） → CoreService（校验策略） → StorageProvider（落地） → AttachmentRepository（入库）
-
-### 5) 映射示例：Settings.Storage 模块
-- PHP 心智：
-  - admin 控制器（配置） → 服务 → `sys_config` 读写（键：`storage_*`）
-- NestJS 对应：
-  - 控制器：`settings/storage/controllers/storage-settings.controller.ts`
-  - 应用：`settings/storage/application/storage-settings.app.service.ts`
-  - Core：`settings/storage/core/services/storage-config.core.service.ts`（唯一启用策略、键名规范）
-  - 仓储接口：`settings/storage/core/repositories/sys-config.repository.ts`
-  - 仓储实现：`settings/storage/infrastructure/sys-config.typeorm.repository.ts`
-  - 实体：`settings/entities/sys-config.entity.ts`（对齐 `sys_config`，字段名：`value`）
-
-流程：Controller → AppService → CoreService（校验/策略） → SysConfigRepository（读写 `value(JSON)`） → 发布事件/入队
-
-### 6) 约束速查（强制对齐）
-- DB 字段：实体字段名/类型/时间戳/软删与 SQL 100%一致
-- `sys_config`：统一使用 `value(JSON)`；禁止 `config_value`、`app_type`
-- 路由前缀：管理端 `/adminapi`，前台 `/api`
-- 守卫：管理端控制器统一 `JwtAuthGuard + RolesGuard`
-- DTO：`class-validator`，必要时 `JsonTransformPipe`、`TimestampPipe`
-- 事件/队列：用例完成后发布 `system.settings.*` 等领域事件，耗时逻辑入队
-
-### 7) 反模式（避免踩坑）
-- 在 Controller 中写业务或直接操作 ORM
-- 跳过 Application 层，直接由 Controller 调 Domain/Repository
-- Domain 依赖具体 ORM/外设实现
-- 在 `upload` 模块中放置“配置管理”代码（应全部在 `settings` 模块）
-- `sys_config` 使用不存在字段（如 `config_value`）、添加 `app_type` 过滤
-
-### 8) 决策树（智能体选路）
-- 这是接口/路由吗？→ 放 `controllers`，只做 DTO 校验与调用 AppService
-- 这是业务流程/事务/聚合？→ 放 `application`，完成后发事件/入队
-- 这是纯业务规则/策略？→ 放 `domain/services`
-- 需要访问数据库？→ 定义 `domain/repositories` 接口，在 `infrastructure/repositories` 实现
-- 需要调用外部系统？→ 放 `infrastructure/providers`（或 `vendor/*`），通过接口注入
-- 是系统配置？→ 放 `settings/*`，读写 `sys_config.value(JSON)`，键按约定常量化
-
-### 命名优先级（重要）
-- 在不违反 NestJS 规范与 TypeScript 命名习惯的前提下，**优先沿用 PHP 的业务命名**（含服务方法名、DTO 字段名、配置键名）
-- NestJS 特有文件/类名按规范命名（如 `*.module.ts`, `*.controller.ts`, `*.app.service.ts`, `*.core.service.ts`）
-
----
-以上映射可直接用于指导模块落地与代码评审，智能体在执行任务前请先对照本表完成“位置与职责”的选择。 

admin/docs/src/wwjcloud/ai/rules.md

@@ -1,28 +0,0 @@
-## 规则与规范（AI 执行细则）
-
-### 总则
-- 框架层: 按 NestJS 规范；业务/数据层: 与 PHP 项目 100% 一致
-- 禁止自创 DB 字段/索引；实体必须与 `sql/wwjcloud.sql` 一致
-
-### 分层与依赖
-- 目录: Controller / Application / Core / Infrastructure / Entities / DTO
-- 依赖方向: App → Common → Core → Vendor（严格单向）
-- Repository: 接口在 Core，实现放 Infrastructure；Controller 不直接用 ORM
-
-### 路由与权限
-- 管理端: `/adminapi/{module}/...`，前台: `/api/{module}/...`
-- 管理端控制器统一: `JwtAuthGuard + RolesGuard`
-
-### 数据与配置
-- 配置表: `sys_config.value(JSON)`；禁止 `config_value`、`app_type`
-- 时间戳: int；软删: `is_del`, `delete_time`; JSON: `@Column('json')` 或 text + JSON 序列化
-
-### 验证与错误
-- DTO: `class-validator` 必须；必要时启用 `JsonTransformPipe`、`TimestampPipe`
-- 异常: 全局过滤器统一错误响应；拦截器记录 request-id/trace
-
-### 事件与队列
-- 用例完成后发布领域事件（如 `system.settings.*`）；耗时逻辑入队处理
-
-### 文档与测试
-- Swagger 注解完善；单测/集成/e2e 覆盖关键用例；`npm run build` 必须通过 

admin/docs/src/wwjcloud/ai/workflow.md

@@ -1,173 +0,0 @@
-## 智能体工作流程（多智能体协作)
-
-### 角色定义（按执行顺序标注）
-- S1 需求分析体(Analyzer): 解析需求、对应 PHP/Nest 规范、输出任务切分与验收标准
-- S2 架构治理体(Architect): 校验分层/依赖/目录规范，给出重构建议与边界清单
-- S3 基建接入体(InfraOperator): 接入/校验 Kafka、Redis、队列、事务与配置，提供接入差异与示例
-- S4 开发执行体(Developer): 按规范编码、编写测试、修复构建
-- S5 安全基线体(SecurityGuard): 检查守卫、跨租户(site_id)隔离、敏感信息暴露（开发中与提测前各执行一次）
-- S6 质量门禁体(QualityGate): 聚合 ESLint/TS/覆盖率/e2e 结果，低于阈值阻断合并
-- S7 规范审计体(Auditor): 按清单逐项核查，出具差异报告与修复项
-- S8 上线管控体(Release): 构建、变更说明、灰度计划与回滚预案
-- S9 性能优化体(PerfTuner): 建议缓存/异步化/批处理，识别大对象传输与 N+1（开发后期与上线后持续执行）
-- S10 命名规范体(NamingGuard): 检查文件/类/方法/变量命名规范，确保符合大厂标准（开发中持续执行）
-
-### 串联流程（带顺序）
-1) S1 Analyzer
-- 输入: 业务需求/接口变更/对齐 PHP 的说明
-- 输出: 模块划分、路由表、DTO、实体字段清单、与 DB/ThinkPHP 对照
-
-2) S2 Architect
-- 校验: 模块目录、分层(Application/Core/Infrastructure)、依赖方向(App→Common→Core→Vendor)
-- 输出: 设计说明、端口(Repository/Provider)定义、删除/迁移建议
-
-3) S3 InfraOperator
-- 接入: Kafka/Redis/队列/事务的工程化接入与配置
-- 产物: 接入差异与示例代码（见 integration.md），健康检查/配置项校验清单
-
-4) S4 Developer
-- 实现: Controller 仅路由+DTO校验；AppService 编排；Core 规则；Infra 实现；Entity 对齐 DB
-- 接入: 守卫(RBAC)、Pipes(JSON/Timestamp)、拦截器(请求日志)、事件与队列
-- 测试: 单测/集成/e2e，构建通过
-
-5) S5 SecurityGuard（第一次，开发阶段）
-- 检查: 控制器守卫、site_id 隔离、敏感字段输出、配置权限
-
-6) S6 QualityGate（CI 阶段）
-- 指标: ESLint/TS 无报错；覆盖率≥阈值；e2e 关键路径通过
-- 动作: 不达标阻断合并
-
-7) S7 Auditor（提测前）
-- 检查: 规范清单(见 checklists.md)，字段/命名/路由/守卫/事务/队列/事件 与 PHP/DB 对齐
-- 产物: 差异报告与修复任务
-
-8) S5 SecurityGuard（第二次，提测前）
-- 复检: 重要接口的鉴权/越权/敏感输出
-
-9) S9 PerfTuner（并行/持续）
-- 建议: 缓存、异步化、批量化、索引与查询优化；识别 N+1、大对象传输
-
-10) S10 NamingGuard（开发中持续执行）
-- 检查: 文件命名、类命名、方法命名、变量命名、数据库命名、API命名
-- 输出: 命名规范检查报告、不符合规范的命名列表、修复建议
-- 标准: 严格按照大厂命名规范执行，确保代码可读性和一致性
-
-11) S8 Release
-- 产出: 变更日志、部署步骤、数据迁移脚本、回滚预案
-
-### 关键约束
-- 与 PHP 业务/数据100%一致；与 NestJS 规范100%匹配
-- 禁止创建 DB 不存在字段；`sys_config.value(JSON)` 统一
-- 管理端路由 `/adminapi`，前台 `/api`；统一守卫与响应格式 
-
-### 基础能力检查点（Kafka / Redis / 队列 / 事务)
-- 事务: 仅在 Application 开启；多仓储共享同一 EntityManager；Core 不直接操作事务对象
-- 队列: 用例完成后入队；载荷仅传关键 ID；处理器在 Infrastructure；按队列名分域
-- 事件: 统一用 DomainEventService；事件名 `domain.aggregate.action`；默认 DB Outbox，可切 Kafka
-- Redis: 短缓存配置读取、上传限流/防刷（计数器）、幂等(SETNX+TTL)
-
-### 命名规范（大厂标准）
-
-#### 文件命名规范
-- **目录名**: `camelCase` (如 `event`, `breaker`, `sdk`, `userManagement`)
-- **文件名**: `camelCase.ts` (如 `baseSdk.ts`, `sdkManager.ts`, `userController.ts`)
-- **模块文件**: `*.module.ts` (如 `user.module.ts`, `auth.module.ts`)
-- **控制器文件**: `*.controller.ts` (如 `user.controller.ts`, `admin.controller.ts`)
-- **服务文件**: `*.service.ts` (如 `user.service.ts`, `auth.service.ts`)
-- **实体文件**: `*.entity.ts` (如 `user.entity.ts`, `role.entity.ts`)
-- **DTO文件**: `*.dto.ts` (如 `createUser.dto.ts`, `updateUser.dto.ts`)
-- **守卫文件**: `*.guard.ts` (如 `jwtAuth.guard.ts`, `roles.guard.ts`)
-- **拦截器文件**: `*.interceptor.ts` (如 `logging.interceptor.ts`, `transform.interceptor.ts`)
-- **管道文件**: `*.pipe.ts` (如 `validation.pipe.ts`, `parseInt.pipe.ts`)
-- **装饰器文件**: `*.decorator.ts` (如 `roles.decorator.ts`, `user.decorator.ts`)
-
-#### 类命名规范
-- **类名**: `PascalCase` (如 `UserService`, `AuthController`, `BaseSdk`)
-- **抽象类**: `Abstract` + `PascalCase` (如 `AbstractBaseService`, `AbstractRepository`)
-- **接口名**: `IPascalCase` (如 `IUserService`, `IAuthRepository`, `ISdkManager`)
-- **枚举名**: `PascalCase` (如 `UserStatus`, `AuthType`, `PermissionLevel`)
-- **类型名**: `PascalCase` (如 `UserCreateDto`, `AuthResponse`, `SdkConfig`)
-
-#### 方法命名规范
-- **方法名**: `camelCase` (如 `getUserById`, `createUser`, `validateToken`)
-- **私有方法**: `private` + `camelCase` (如 `private validateInput`, `private processData`)
-- **异步方法**: `async` + `camelCase` (如 `async getUserById`, `async createUser`)
-- **布尔方法**: `is`/`has`/`can` + `PascalCase` (如 `isValid`, `hasPermission`, `canAccess`)
-
-#### 变量命名规范
-- **变量名**: `camelCase` (如 `userName`, `authToken`, `configData`)
-- **常量名**: `UPPER_SNAKE_CASE` (如 `MAX_RETRY_COUNT`, `DEFAULT_TIMEOUT`, `API_BASE_URL`)
-- **私有变量**: `private` + `camelCase` (如 `private logger`, `private configService`)
-- **只读变量**: `readonly` + `camelCase` (如 `readonly appName`, `readonly version`)
-
-#### 数据库命名规范
-- **表名**: `snake_case` (如 `sys_user`, `user_role`, `auth_token`)
-- **字段名**: `snake_case` (如 `user_name`, `created_at`, `is_deleted`)
-- **索引名**: `idx_表名_字段名` (如 `idx_user_email`, `idx_user_status`)
-- **外键名**: `fk_表名_引用表名` (如 `fk_user_role_user_id`)
-
-#### API命名规范
-- **路由前缀**: 
-  - 管理端: `/adminapi` (如 `/adminapi/user`, `/adminapi/auth`)
-  - 前台: `/api` (如 `/api/user`, `/api/auth`)
-- **端点名**: `kebab-case` (如 `/user-management`, `/auth-token`)
-- **HTTP方法**: 标准方法 (GET, POST, PUT, DELETE, PATCH)
-
-#### 配置命名规范
-- **环境变量**: `UPPER_SNAKE_CASE` (如 `DB_HOST`, `REDIS_PASSWORD`, `JWT_SECRET`)
-- **配置键**: `camelCase` (如 `database.host`, `redis.password`, `jwt.secret`)
-- **配置组**: `camelCase` (如 `database`, `redis`, `jwt`, `app`)
-
-#### 特殊命名约定
-- **PHP业务命名优先**: 在符合NestJS/TS规范前提下，优先使用PHP业务术语
-- **NestJS特有类型**: 严格按框架规范命名
-- **避免缩写**: 使用完整单词，提高可读性
-- **语义化命名**: 名称应清晰表达用途和含义
-
-#### 命名检查清单
-- [ ] 文件名使用 `camelCase.ts`
-- [ ] 类名使用 `PascalCase`
-- [ ] 接口名使用 `IPascalCase`
-- [ ] 方法名使用 `camelCase`
-- [ ] 变量名使用 `camelCase`
-- [ ] 常量名使用 `UPPER_SNAKE_CASE`
-- [ ] 表名使用 `snake_case`
-- [ ] 环境变量使用 `UPPER_SNAKE_CASE`
-- [ ] 避免使用缩写
-- [ ] 名称语义清晰
-
-### 命名与对齐
-- PHP 业务命名优先（不违反 Nest/TS 规范前提下），包括服务方法、DTO 字段、配置键
-- Nest 特有类型按规范命名：`*.module.ts`、`*.controller.ts`、`*.app.service.ts`、`*.core.service.ts`
-
-### 核心链接
-- 模块映射: `./mapping.md`
-- 能力集成: `./integration.md`
-- 规则与清单: `./rules.md`、`./checklists.md`
-
-### 执行与验收（CI/PR 建议)
-- PR 必须通过: build、单测/集成/e2e
-- 审计体根据 `checklists.md` 自动评论差异（字段/命名/路由/守卫/事务/队列/事件）
-- 命名规范体(NamingGuard)检查所有文件命名、类命名、方法命名、变量命名
-- 安全基线: 管理端控制器统一 `JwtAuthGuard + RolesGuard`；/adminapi 与 /api 路由前缀 
-
-### 目录职能速查（防误用）
-- common/（框架通用服务层）
-  - 放可被业务复用的通用功能：用户/权限/菜单/上传/通知/设置等模块
-  - 内部模块按 Controller / Application / Core / Infrastructure / Entities / DTO 分层
-  - 禁止依赖 App 层；允许依赖 core/, config/, vendor/
-- config/（配置与适配）
-  - 环境变量、数据库/HTTP/安全/队列/第三方等配置模块与注入工厂
-  - 仅存放配置与适配代码，不放业务逻辑
-- core/（核心基础设施与通用规则）
-  - 通用规则/策略与仓储接口（Core 层），以及全局基础设施（如队列、事件、健康、拦截器）
-  - 不直接依赖业务模块；面向 common/app 提供能力
-- vendor/（第三方适配层）
-  - 外部服务适配：存储/支付/短信/HTTP/Kafka/Redis 等 Provider
-  - 通过接口注入到 Infrastructure 或 Application，避免在 Controller 直接使用
-- lang/（多语言）
-  - 多语言资源与语言包，供接口/异常/文案统一输出
-  - 智能体在涉及文案/错误消息时，优先调用多语言键值而非写死文本
-- test/（测试）
-  - 单元/集成/e2e 测试，包含关键业务与基础能力（事务/队列/事件/权限）覆盖
-  - PR 必须通过测试基线，质量门禁体(QualityGate)据此决策