feat(product): 新增产品管理模块与字典组件功能

- 新增产品管理相关路由和页面（dashboard、list、requirement、setting）
- 实现产品基础信息编辑弹窗组件（base-info-dialog.vue）
- 添加运行时字典功能（dict-select、dict-text、dict-tag组件）
- 集成字典管理store和API调用
- 规范ID类型定义为string避免精度丢失问题
- 完善国际化资源文件支持中英文对照
- 新增对象上下文业务域入口页导航实现说明
- 添加Vue DevTools浮动入口注释说明
- 统一权限控制支持全局和对象作用域区分
- 规范分页查询参数类型定义与使用方式

AGENTS.md

@@ -85,6 +85,15 @@
 - 常量路由维护入口优先是 `build/plugins/router.ts` 和 `src/router/routes/custom-routes.ts`，不要把常量路由散落到业务页面逻辑里。
 - 菜单图标约定属于路由契约的一部分：`meta.icon` 表示 Iconify 图标，`meta.localIcon` 表示本地 SVG 图标；不要混用字段语义。
 
+### 对象上下文业务域入口页口径
+
+- `product`、`project` 这类对象上下文业务域的入口页，按 `docs/rdms/rdms-object-context-navigation-implementation-notes.md` 口径，本来就是“先进入业务域入口页，再选择对象建立上下文”；不要把“入口页是可点击菜单”误判成配置错误。
+- 对象上下文业务域的“入口态”页面，例如 `product_list -> /product/list -> view.product_list`，可以作为左侧一级入口菜单实际命中的页面；这不等于已经进入对象上下文态。
+- 不要为了修复“点击入口页后只剩内容页、布局壳消失”的问题，直接要求把对象域入口菜单从“菜单”改成“目录”。先检查当前是不是动态权限路由模式，以及后端 `get-user-routes` 返回是否缺少业务域根路由。
+- 在 `VITE_AUTH_ROUTE_MODE=dynamic` 下，如果后端只返回对象域入口叶子页，而没有返回本地静态骨架中的业务域根路由，例如缺少 `product -> layout.base`、只返回 `product_list -> view.product_list`，前端必须在动态路由归一化阶段补回本地业务域骨架，而不是让入口页直接裸挂成顶层 `view.*` 路由。
+- 对象上下文业务域的稳定来源仍应是本地路由骨架：业务域根路由负责 `layout.base`，入口页负责对象列表或对象选择，真正的对象功能页继续挂在该业务域下。动态路由兼容逻辑只能做“补骨架”和“对齐入口”，不要反过来推翻这层结构。
+- 后续新增新的对象上下文业务域时，至少同步检查这几处是否闭环：本地静态路由骨架、`src/constants/object-context.ts` 中的 `domainKey / entryRouteKey / entryRoutePath / fallbackDefaultRouteKey`、动态路由归一化逻辑、对象上下文 store 与头部菜单切换逻辑。
+
 ## 分层职责约束
 
 ### `src/views`
@@ -158,6 +167,40 @@
 - 涉及路由、菜单、权限的改动时，同时检查 `build/plugins/router.ts`、`src/router/routes/*`、`src/store/modules/route/*` 和相关文档。
 - 对于可再生的路由产物，优先修改源配置并执行 `pnpm gen-route`，不要把手工修补生成文件当成常规方案。
 
+## 运行时字典使用口径
+
+- 运行时字典统一由 `src/store/modules/dict/index.ts` 管理，登录后通过 `/system/dict-data/frontend-cache` 初始化；不要在业务页面重复直调字典接口。
+- 字典编码常量优先收敛在 `src/constants/dict.ts`，不要在页面里散落硬编码 `dictType`。
+- 不要猜测字典编码。新增某个业务字段对应的字典前，先从“后端接口文档、后端字段契约、系统字典管理页”确认真实 `dictType`，再写入 `src/constants/dict.ts`。
+- `src/constants/dict.ts` 中每个导出的字典常量，尽量补中文注释，至少说明两件事：对应哪个业务字段、这个编码是从哪里确认出来的。
+- 如果后端实际 `dictType` 带有历史命名痕迹，例如当前对象方向仍叫 `rdms_product_direction`，前端常量名优先按真实业务语义命名，不要继续把历史误导扩散到页面代码里。
+- 表单下拉优先使用 `src/components/custom/dict-select.vue`。
+- 普通文案回显优先使用 `src/components/custom/dict-text.vue`。
+- 需要标签态回显时优先使用 `src/components/custom/dict-tag.vue`，标签颜色仍由业务页面自己决定。
+- 在 `script setup`、TSX 列格式化、复杂判断里，优先使用 `src/hooks/business/dict.ts` 提供的 `useDict(dictCode)`，常用能力包括 `dictOptions`、`getItem`、`getLabel`、`getLabels`、`hasValue`。
+- `DictSelect` 默认只展示启用项；确实需要包含禁用项时，显式传 `:only-enabled="false"`。
+
+简单示例：
+
+```vue
+<DictSelect v-model="form.directionCode" :dict-code="RDMS_OBJECT_DIRECTION_DICT_CODE" />
+<DictText :dict-code="RDMS_OBJECT_DIRECTION_DICT_CODE" :value="row.directionCode" />
+<DictTag :dict-code="SYSTEM_USER_COMPANY_DICT_CODE" :value="row.companyCode" type="info" />
+```
+
+```ts
+const { getLabel, getLabels } = useDict(RDMS_OBJECT_DIRECTION_DICT_CODE);
+
+const directionLabel = getLabel(row.directionCode);
+const directionLabels = getLabels(row.directionCodes, { separator: '，' });
+```
+
+确认字典编码的典型方式：
+
+- 后端接口文档直接写明字段使用哪个字典，例如产品 `directionCode -> rdms_product_direction`；如果该编码只是历史命名，前端常量名仍按通用业务语义命名。
+- 当前系统已有页面或接口已经稳定使用某个字典，例如用户所属公司 `company -> system_user_company`。
+- 如果以上两种都没有，就先让后端或业务明确 `dictType`，不要前端自己命名。
+
 ## 页面资源与菜单目录约束
 
 - 页面组件键、页面资源、菜单目录是三层不同概念，不要把它们当成同一个值。
@@ -170,6 +213,15 @@
 
 - 优先使用现有别名导入（`@/...`、`~/...`），避免过长的相对路径。
 - 保持与 TypeScript 严格模式兼容。
+- 后端返回的主键 ID、用户 ID、对象 ID、雪花 ID、Long ID 等，一律优先按 `string` 在前端接收和传递，不要默认写成 `number`。
+- 这是强约束，不是建议项。原因包括：JavaScript `number` 无法稳定承载长整型精度、接口序列化后可能出现精度丢失、运行时还容易出现 `number/string` 键不一致，最终导致回显、筛选、映射、路由参数、对象上下文等逻辑异常。
+- 这条约束要落实到所有层：`typings`、API 返回类型、页面表单 `model`、组件 `props` / `emits`、`ElSelect` 的 `value`、路由参数、查询参数、`Map` 键、筛选条件、store 状态，一律优先使用 `string` / `string[]`。
+- 明确禁止把 ID 当成普通数值处理。禁止写法包括但不限于：`Number(id)`、`+id`、`parseInt(id)`、`parseFloat(id)`、`Math.floor(id)`，以及任何“为了比较、传参、回填、提交而把 ID 转成 number”的做法。
+- 比较、映射、筛选 ID 时，默认按字符串语义处理，例如 `id === targetId`、`Map<string, T>`、`Set<string>`，不要混用 `number/string` 双口径。
+- 如果后端当前接口暂时还返回数值型 ID，前端也必须尽可能在 `typings`、API 适配层或进入业务层前转成 `string`，不要把 ID 按 `number` 扩散到页面、store 和组件里。
+- 但要注意：如果后端把超出 JS 安全整数范围的 Long 直接作为 JSON 数字返回，前端在业务层再 `String(number)` 只能得到“已经丢精度后的错误字符串”。这种情况必须明确记为接口契约风险，不要误判为“前端已安全处理”。
+- 因此，新增或改造接口时，最稳妥的契约仍然是：后端长整型 ID 直接按字符串返回；前端全链路按字符串接收和传递。若后端暂未改，前端侧也不得新增 `number` 口径 ID 用法。
+- 对仓库中的历史代码，原则是“不再新增 number 口径 ID，当前任务触达相关链路时优先顺手矫正”；不要继续复制历史写法。
 - 遵循仓库现有的 Vue SFC 风格：`script setup`、类型化 store、职责单一的小型 composable/helper。
 - 修改界面时优先延续 `src/layouts` 和 `src/theme` 中已有的 UI 模式，不要平行引入另一套设计体系。
 - 注释保持克制，只在代码本身不够直观时补充必要说明。