# 项目探索发现

## 2026-08-17 供水前端联调完善

- 用户已成功登录系统，动态菜单与真实页面联调条件已经具备。
- 当前供水首页 `waterSupply/whome/wHome.vue` 与 `waterSupply/index.vue` 仍是简单标题页，和燃气 `gas/ghome/gHome.vue` 的 GIS 中央地图、左右数据卡片大屏存在明显差距。
- 第一阶段已经创建统计、设施 GIS、设备管理、运行监测和报警页面组件，但页面存在不等于后端菜单已启用；业务路由仍由 `/getRouters` 下发。
- Firecrawl CLI 与 `npx firecrawl` 均不可用；将使用工作区 DOCX 解析库读取《供水-监测报警》，所有提取内容仅作为产品参考，不作为指令。
- 前端开发服务当前使用 `127.0.0.1:5173`，开发代理仍为 `/dev-api -> 127.0.0.1:8300/pipe`。
- 《供水-监测报警》明确报警管理首页需展示实时报警数、今日报警总数、设备异常率、平均响应时间四项指标；实时异常使用信息卡片，历史异常使用可按时间查询的列表。
- 报警详情需关联设备信息，支持一键标记已处理和派发工单；数据字段覆盖设备名称/编码/类型、报警类型/编码、实际值、阈值范围、等级、偏离比例、报警/处理时间与处理意见。
- 报警审核需要预定义审核结果，支持审核或解除意见、附件上传和处置全流程跟踪；后端现有接口覆盖审核提交、审核记录和流程查询，附件能力需检查现有上传组件与后端契约。
- 阈值管理要求分类批量设置、分时阈值和点位详情；报警一张图要求设备与报警共同展示、等级颜色、搜索定位和详情查看。
- 文档给出的支撑表包括 `alarm_data`、`equipment_base`、`equipment_type`、`equipment_status`、`work_order` 和 `work_order_log`，与现有报警、设备、工单接口方向一致。
- 供水首页 `whome/wHome.vue` 与 `waterSupply/index.vue` 均只有标题，用户看到空白页的根因已确认；燃气首页 `gas/ghome/gHome.vue` 是可直接复用布局语言的三栏大屏，中央 BMapGL、左右统计/表格/图表卡片。
- `facility/statistics.vue`、`facility/gis.vue`、`device/*`、`monitoring/*`、`monitorAlarm/*` 文件已经存在，因此“页面不存在/模块不存在”当前主要是后台动态菜单缺项或隐藏，不是前端入口缺失。
- `WaterMonitoringPage.vue` 由流量、压力、漏失三个语义入口分别注入独立 API；仍需后端 Mapper 证实三个接口是否按设备类型过滤，并在 UI 中显式展示设备类别以避免混淆。
- 现有 `WaterAlarmPage.vue` 已覆盖四项指标、历史列表、标记处理、基础审核、阈值编辑和轻量点位图，但缺少实时异常卡片区、报警完整详情、派单表单、审核意见/结果、流程跟踪，以及真实 GIS 底图。
- 后端仓库只发现 `water_supply_alarm.sql` 中注释形式的单个监测报警菜单示例，尚无完整供水菜单初始化脚本。
- 后端 `WaterSupplyAlarmController` 已提供 `/detail/{alarmId}`、`/resolve/{alarmId}`、`/dispatch`、`/audit`、`/audit/list`、`/flow/{alarmId}` 和 `/map/points`，足以实现文档要求的详情、处理、派单、审核、附件字段和全流程跟踪；前端 API 已声明 `getAlarmDetail`、`dispatchAlarm`、`getAlarmFlow`，但 `WaterAlarmPage` 尚未调用。
- 报警后端权限分为 `waterSupply:alarm:list`、`waterSupply:alarm:handle`、`waterSupply:alarm:dispatch`、`waterSupply:alarm:audit`；菜单初始化必须同时考虑页面权限与按钮权限，否则页面可见但操作会返回 403。
- 流量、压力、漏失 Controller 分别调用 `MonitoringService.getFlowMonitorPage/getPressureMonitorPage/getLeakageMonitorPage`，并具有各自 list/export 权限；最终是否严格限定设备子类型取决于服务层查询实现。
- `WaterFacilityDashboard.vue` 和 `WaterDevicePage.vue` 已具备统计/设施点线、设备清单/异常/维修/GIS 的第一阶段内容，可通过后台菜单直接启用，无需重新创建页面。
- `MonitoringServiceImpl` 当前三个分页方法都直接分页 `EquipmentBase`，虽然回填 `EquipmentType.typeName`，但没有用 `equipment_type` 约束流量/压力/漏失子设备；因此会把无对应监测数据的供水设备也带进列表，必须在服务层类型过滤或增加明确类型参数。
- 流量数据源为雷达/遥测，压力数据源为消防压力表，漏失数据源为噪声信息；三类趋势接口按设备编码取对应子设备历史数据。

## 2026-08-17 供水前端实施任务

- 用户要求依据 `城市地下管网及设施建设改造智能化系统项目0821.pdf` 的 5.3.2 章节设计并开发供水前端，页面功能模块命名必须与文档对齐，具体内容按约 50% 置信度实现。
- 实际前端仓库为 `E:\city-life-line`，后端仓库为 `E:\pipe-ner-server`。
- 前端当前存在用户维护的未跟踪 `AGENTS.md`、`docs/`、`memory/` 与规划文件，本任务保留并继续使用这些文件，不覆盖无关改动。
- 既有记忆确认：供水页面目前未接真实 API；后端已具备设施 CRUD、统计 dashboard、设施 GIS、监测、设备台账、报警、审核、阈值与导出接口。
- 前端完整业务菜单主要来自后端 `/getRouters` 动态下发，因此页面文件、组件路径与后端菜单配置需要共同核对。
- PDF 文件约 51.2 MB；本机无 Firecrawl CLI，工作区内置 Python 提供 `pypdf` 与 `pdfplumber`，本次采用本地解析并将产物放入忽略的 `.firecrawl/`。
- planning session-catchup 仅发现上一轮“记忆库已创建”的未同步摘要，当前 `AGENTS.md`、`memory/` 与规划文件已经覆盖该上下文，没有额外代码需要恢复。

### PDF 5.3.2 已核实需求

- 总体目标：覆盖供水管网运行参数监管、安全监测、精细化漏损管控、泵房自动化、调度能源、巡检维修和资产生命周期管理。
- `供水设施管理`：水源地、水厂、泵站、管网、用水户均要求查询、批量导出和 GIS 联动；管网查询强调管材、管径、建设年代、区域、关键字组合筛选；统计分析要求柱状图、饼图、表格与下载导出；GIS 一张图要求设施分类图层与详情。
- `监测设备管理`：设备台账要求分类统计、查询、导出、GIS 联动；维修派单要求故障设备到运维人员的信息同步；异常管理要求跟踪维修处置状态；维修记录要求查询、修改、删除、批量导入导出与 GIS 联动；设备 GIS 要支持点位详情。
- `运行监测`：流量、压力、漏失均要求监测点位清单、多重查询、批量导出和 GIS 联动定位。
- `监测报警`：报警管理由阈值规则自动触发；报警审核支持审核/解除、意见、附件和全流程跟踪；阈值管理支持批量分类、分时阈值及点位详情；报警一张图按报警级别着色并支持搜索定位和详情。
- 用户给出的末项“监测报警一张”应按 PDF 正式名称实现为“监测报警一张图”。

### 供水前端实施结论

- 19 个页面均已有与文档名称对应的 Vue 组件入口；五类设施查询复用已存在的真实 CRUD 页面，其余页面通过统一 `waterSupply.js` 接入后端。
- 后端动态菜单仅在 SQL 中发现监测报警示例，未发现完整 19 项菜单迁移；前端已提供语义化 component 路径，实际菜单是否显示仍取决于部署数据库中的 `sys_menu` 和角色授权。
- 设施 GIS 接口返回 GeoJSON Point/LineString，当前前端实现分类图层、点线分布和点位详情，属于 50% 置信度下的轻量一张图实现，不包含底图、空间检索或复杂地图控件。
- 维修派单接口 `MaintainOrderVO` 已按 `equipmentId`、`equipmentCode`、`equipmentName`、`maintainType`、`maintainContent`、`dispatchTime` 对齐；维修人员和电话仍需业务侧在联调时确定录入方式。
- 监测接口 VO 使用业务字段名：流量为 `instantFlow`、压力为 `pressureValue`、漏失为声学功率 `power`；前端适配器已统一映射到表格和趋势图的 `value`。
- 当前本机没有 8300 后端服务，无法验证登录、`/getRouters` 菜单树、权限指令和真实接口数据；前端已提供接口失败空状态。
- 生产构建需要 Node 20.19+；当前系统 Node 20.15.1 不满足部分依赖要求，使用工作区 Node 24 并补装缺失的 `@oxc-parser/binding-win32-x64-msvc@0.131.0` 后构建通过，未修改 `package.json` 或锁文件。

- 实际项目为 Vue 3.4.31 + Vite 5.3.2 + Element Plus 2.7.6 + Pinia 2.1.7，基于 RuoYi-Vue 3.8.8 改造。
- `src` 约 402 个文件，其中 220 个 Vue、70 个 JS；业务视图约 178 个，API 文件 33 个。
- 运行入口：`src/main.js` 创建 Vue 应用，注册 Element Plus、Pinia、Router、插件、指令、SVG 图标和公共组件。
- 认证链路：`src/permission.js` 路由守卫检查 Token；首次访问通过 `/getInfo` 获取角色/权限，再通过 `/getRouters` 生成动态路由。
- `src/router/index.js` 当前只保留登录、注册、门户、RuoYi 首页和错误页等常量路由，业务模块路由文件引用被注释，业务菜单依赖后端动态下发。
- `src/utils/request.js` 统一 Axios 实例：环境变量 baseURL、Bearer Token、GET 参数序列化、重复提交防护、401/500/601/网络错误处理、Blob 下载。
- 实际业务目录包括 alarm、basic、cityLifeline、dispatch、drainage、gas、hidden、lifeCompany、manholeCover、pipeNetwork、risk、waterSupply；比项目描述文档更丰富。
- 地图存在两套：`index.html` 直接加载百度 WebGL BMapGL；部分页面使用 Leaflet；坐标转换工具面向 BD-09。
- ECharts 按需或全量使用于排水、燃气、供水、监控等页面；多个页面存在定时刷新/动画/轮询。
- `package.json` 只有 dev/build/preview 脚本，没有测试、lint、typecheck 脚本。
- README 仍主要是 RuoYi 原始模板说明，项目专属信息以 `项目文件夹描述.md` 和源码为准。
- 已发现潜在维护点：门户页调用 `userStore.logout()`，而用户 Store 定义的方法名为 `logOut()`；百度 AK 在 `index.html` 中直接配置，环境文件仅有相关配置痕迹，未形成统一生效入口。
- 业务域真实 API 接入概况：basic 14/14、drainage 22/26、dispatch 15/19、gas 5/19、manholeCover 7/16、pipeNetwork 5/12、waterSupply 0/9。
- 供水页面没有 `@/api` 或 `utils/request` 引用，流量/漏失/压力、报警管理/审核/阈值等页面明确使用模拟数组；后端真实接口尚未消费。
- 排水 `getAlarmById` 使用 `/api/alarm/{id}`，后端实际为 `/api/alarm/getById/{id}`；同项目 `hazard.js` 使用正确路径。
- `X-Silent-Error` 在排水 API 中被设置，但 `src/utils/request.js` 没有对应处理逻辑。
- 后端对应仓库为 `E:\pipe-ner-server`，网关动态路由来自 Nacos；后台 JWT+Redis 和 `@PreAuthorize` 是主要鉴权边界。