## Context

当前 `#/reference/wechat` 是不请求接口的静态旧界面参考，而 `as_wecom_account` 已经具备 `WecomAccountEntity` 和 `WecomAccountMapper`，尚未具备列表 Service、Controller、DTO 与真实前端页面。资产人员需要查看企微资料的全部业务字段，并将公司档案、手机号资产、设备、经办人等关联 ID 理解为可读名称。

约束：本次只读主数据源，不修改表结构、不新增编辑删除能力；`delete_time` 延续现有手机号资产规则，仅用于过滤；用户已确认它不应返回或展示。

## Goals / Non-Goals

**Goals:**

- 提供 `#/reference/wecom` 的可筛选、可分页企微资产列表。
- 提供 `GET /api/wecom-accounts`，返回企微字段、创建/更新时间、关联 ID 及关联名称。
- 将 `realNameOwner` 以“企微实名人”展示。
- 对每页记录的关联 ID 批量解析公司名称、手机号、设备名称和经办人名称。

**Non-Goals:**

- 不显示或返回 `deleteTime`，不查询已删除记录。
- 不变更 `as_wecom_account` 或任何关联表的数据库结构与数据。
- 不实现新增、编辑、删除、导入、导出或权限模型。
- 不为不存在或已删除的关联记录自动修复数据。

## Decisions

### 新路由与旧路由

导航与真实页面使用 `#/reference/wecom`，并移除 `#/reference/wechat` 的静态企微参考页。采用直接替换而非保留别名，原因是需求明确要求将 wechat 换为 wecom；继续保留旧页会让用户进入过时且无真实数据的界面。

### 分页与筛选契约

接口使用现有手机号资产的 `page`、`size` 约定：默认第 1 页、每页 20 条、最大 100 条；支持精确筛选 `wecomName` 与 `wecomAccount`。查询显式限定 `delete_time = 0` 并按 `id` 倒序，保证与既有资产列表的正常记录定义一致。

### 关联 ID 与名称

响应同时返回原始 ID 和显示名称：`companyProfileId/companyProfileName`、`phoneAssetId/phoneNumber`、`deviceId/deviceName`、`operatorPersonId/operatorPersonName`。Service 收集当前页各类非空 ID 后，分别以 `IN` 条件批量查询关联表并构建 ID 到名称的映射。

批量查询（一次取得当前页所有关联记录）优于逐行查询，避免一页 20 条企微记录触发数十次数据库访问、导致列表加载变慢。关联 ID 未匹配记录时保留 ID，名称返回 `null`，前端显示“—”，不掩盖数据关系异常。

### 字段暴露与页面展示

响应和表格展示 `id`、企微名称、别名、账号、公司档案 ID/名称、手机号资产 ID/手机号、企微实名人、实名状态、性别、设备 ID/名称、经办人 ID/名称、创建时间和更新时间。`deleteTime` 只在 Service 查询条件中使用，既不写入响应 DTO，也不创建表格列。

## Risks / Trade-offs

- [历史数据的 `delete_time` 为 `NULL`] → 现有手机号列表以 `0` 表示正常，本期保持一致；上线前使用只读查询确认实际数据约定，必要时另行提出兼容变更。
- [关联记录缺失或已删除] → 保留原关联 ID，名称显示“—”，便于定位而不阻塞企微主记录显示。
- [个人信息展示范围扩大] → 当前需求明确展示企微实名人和手机号；后续如引入权限规则，再单独设计脱敏或字段授权。
- [路由书签失效] → 按确认的直接替换执行；发布说明标注新的 `#/reference/wecom` 地址。

## Migration Plan

1. 先添加后端 Controller 测试与前端路由/列表测试，定义新路由和只读响应。
2. 新增 DTO、Service、Controller 及前端列表页面，不改动既有实体、Mapper 和表。
3. 将导航和路由从 wechat 迁至 wecom，并移除企微静态参考测试。
4. 执行后端编译与测试、前端构建及 Playwright；失败时回退本变更的前端/后端代码和路由，不执行数据库回滚。

## Open Questions

- 无；字段展示、关联名称、路由替换和 `deleteTime` 不展示均已确认。
