## Context

当前系统无字典管理功能。多个模块（组织管理、站点管理、角色管理等）依赖字典编码进行状态/分类映射（如 zzlbbm、bmzt、zdlx、zdywfw）。数据库表 `sys_dict_type` 和 `sys_dict_data` 已在 DDL 中定义，但后端无对应模型、CRUD、API 路由，前端无对应页面。

**现有代码模式参考：**
- 后端：`crud/tenant.py` 的独立函数模式（`list_*, get_*, create_*, update_*, soft_delete_*`），`api/admin.py` 的路由模式
- 前端：`views/system/unit/index.vue` 标准列表模板，`api/admin.ts` 的 `request.get/post/put/del` 模式
- 模型：`models.py` 中直接使用 `from app.core.database import Base`，公共字段顺序遵循 V0.3 约定

## Goals / Non-Goals

**Goals:**
- 提供字典类型的完整 CRUD（分页列表、新增、修改、软删除）
- 提供字典数据的完整 CRUD（按字典类型分组，支持新增、修改、软删除）
- 前端字典类型列表页 + 字典数据配置弹窗
- 严格遵循租户隔离、软删除、默认排序等工程规范
- 初始化字典数据脚本（zzlbbm、bmzt、zdlx、zdywfw）

**Non-Goals:**
- 字典缓存机制（后续优化）
- 字典数据批量导入导出
- 字典变更审计日志
- 小程序端字典管理

## Decisions

### D1: 后端 CRUD 采用独立函数模式（非 CRUDBase 泛型）

**选择**: 参照 `crud/tenant.py` 的独立函数 + `_row_to_dict()` 模式
**理由**: 现有业务模块（tenant）均使用此模式，保持一致性比引入新模式更重要
**替代方案**: 使用 `crud/base.py` 的 `CRUDBase[Model]` 泛型 → 被弃用，因为 tenant 模块未使用，且手动函数更灵活

### D2: 字典 API 路由注册在 admin.py

**选择**: 在现有 `api/admin.py` 中新增字典路由组
**理由**: 字典属于系统管理范畴，与 tenant 同属 admin 路由前缀 `/web/admin`。模块较少，无需新建文件
**替代方案**: 新建 `api/system.py` → 可行但当前系统管理模块可集中管理

### D3: 字典数据查询通过 dict_type 关联

**选择**: 字典数据列表按 `dict_type` 过滤查询，前端弹窗传入 `dict_type` 获取对应字典数据
**理由**: 需求文档明确"点击字典数据配置按钮弹出弹窗"，弹窗需知道当前字典类型

### D4: 前端字典数据配置弹窗采用 Dialog + 内嵌表格

**选择**: 字典类型列表页 + 点击"字典数据配置"弹出 Dialog，Dialog 内展示该类型的字典数据表格，支持行内新增/编辑/删除
**理由**: 需求文档 2.1.2 描述的交互模式

## Risks / Trade-offs

- **[字典类型编码唯一性]** dict_type 在同一 tenant 下需唯一 → 通过数据库唯一索引 `uk_dict_type` + 应用层校验双重保障
- **[字典数据量]** 某些字典类型数据较多 → 弹窗内分页查询，每页 20 条
- **[初始化数据]** 需要确保系统初始化时有基础字典数据 → 提供独立 SQL 初始化脚本