city-life-line/findings.md

项目探索发现

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 是主要鉴权边界。