Начало Каталог Помощ
Регистрация Вход
shaoy
/
city-life-line
1
0
Разклонения 0
Файлове Задачи 0 Заявки за сливане 0 Уики
ИН на ревизия: d38d35e4c6
Клонове Маркери
city-life-line
/
memory
/
long-term.md

long-term.md 19 KB
История Директен файл

城市生命线长期记忆

项目定位

这是“城市地下管网及设施建设改造智能化系统项目”软件平台中“地下管网管控平台”的 Vue 3 前端，覆盖燃气、排水、供水、管网基础、告警、风险和应急调度等业务域。供水前端与 E:\pipe-ner-server\pipe-network-service 后端共同构成“供水管网安全运行监测系统”。

技术架构

  • Vue 3 + Vite
  • Element Plus + Pinia
  • UnoCSS + SCSS
  • Axios 统一请求层，使用 JWT 鉴权
  • 百度地图 WebGL 与 Leaflet 并存
  • ECharts 用于监测、统计和大屏可视化
  • 业务路由由后端菜单和权限动态生成
  • 对应后端仓库为 E:\pipe-ner-server；管理后台基于 Spring Boot/RuoYi，网关路由由 Nacos 动态配置。

当前功能成熟度

  • 基础台账、排水、应急调度的前端 API 接入相对完整。
  • 燃气、井盖、管网页面为真实接口与模拟数据混合。
  • 供水 19 个页面已按项目文档 5.3.2 命名完成第一阶段实现；五类设施 CRUD 复用既有页面，设备、运行监测、报警、统计和轻量 GIS 已接后端真实接口，后续按完整供水子系统验收。
  • 供水 T3 统计（Issue #7）与 T4 运行监测（Issue #8）已人工验收通过并在 Gogs 关闭（2026-09-05）。

启动约定

  • 使用 npm，不依赖 Yarn。
  • 开发命令：npm run dev
  • 默认前端地址：http://localhost:80
  • 备用端口：npm run dev -- --port 5173
  • 开发代理：/dev-api → 本机 8300/pipe 后端
  • 正常登录和业务菜单需要对应后端服务运行。

记忆库约定

  • 每次对话结束后更新当天的 memory/sessions/YYYY-MM-DD.md。
  • 稳定决策和长期有效事实同步到本文件。
  • 每累计 5 次会话或单日记录超过约 20 KB 时整理长期记忆。
  • 不记录密码、Token、API 密钥、地图密钥、内部账号或个人隐私。

用户已确认决策

  • 移动端专用接口统一放到后端 zksy-admin 的 com.zksy.web.controller.mobile，与 PC 共用现有业务 Service，数据权限也留在 Service 校验；不复制移动端业务流程。七类 Controller 的 URL 统一为 /api/mobile/...：工单 /ops/workOrder、巡检 /ops/inspectTask、设备 /equipment-base、故障通知 /alarm、公告 /notice、本人登录日志 /monitor/logininfor/list、通讯录 /contacts（均接在统一前缀后）。移动端调用同步更新，不保留旧移动端专用双路由；此决定取代同日初版保留旧 URL 的约定。登录、资料、通用上传及工单处置等两端共用接口仍保留原入口；报警不再单设 MobileAlarmService（2026-10-14）。
  • 移动端“我的－基本资料”性别仅提供男（0）、女（1）两个 radio 单选项，不再提供保密或下拉选择。历史保密（2）或未设置的资料显示为未选中，保存前需明确选择男或女，避免静默修改性别（2026-10-14）。
  • 移动端“日常－故障通知”按当前用户部门自身或祖先 101/102/103 对应设备类型的直接 parent_id=1/2/3 过滤，不包含共享类型 4，也不扩展类型树；管理员同样按公司范围读取，客户端 rootTypeId 只能收窄。已转工单通过 work_order.device_id 关联设备，未转工单按报警设备编码关联；关联损坏不可回退放宽。列表与 PC 审核页一致只查未处理报警，右上角展示待核实/确认报警/误报警；顶部按全部/待核实/确认报警/误报警分 tab，报警等级下拉放在搜索输入框前，使用工单同款公共搜索栏。详情用“故障信息/处置全流程”左右页签，待核实且未处理并有 alarm:review:audit 权限时提供底部“核实”抽屉。移动端状态0统一显示“待核实”，操作与表单使用“核实”文案，PC 同步使用“待核实/核实”，接口枚举和权限保持原约定。核实结果必选、意见选填最多500字、图片最多5张（JPG/JPEG/PNG、每张10MB），复用 PC 附件票据和审核事务。历史沿用 alarm_log，不复制工单日志（2026-10-14）。
  • PC 与移动端报警业务统一展示“待核实/核实”：PC 共享列表、详情、提醒、研判、供水首页及台账导出同步；菜单旧标题“报警审核”由前端按报警组件映射为“报警核实”，兼容后端旧状态名，不修改数据库菜单、接口枚举、路由或权限。工单验收与延期仍使用审核文案（2026-10-14）。
  • 移动端照片预览按同一业务组连续切换，维修前、维修后、每条工单日志附件和巡检现场照片分别成组；工单详情无可执行操作时不展示底部提示栏（2026-10-14）。
  • 移动端“我的－登录日志”仅查询当前登录用户本人，管理员也不例外；服务端从登录态获取账号，按 sys_logininfor.user_name 精确匹配，不复用 PC 日志列表的账号模糊查询（2026-10-14）。
  • 工单仅在待派单（0）、待接单（1）时允许取消；移动端、PC 端展示和后端校验统一限制，保留既有取消权限与数据范围（2026-10-14）。
  • 移动端真实接口列表统一采用“首次进入加载 + 用户下拉刷新”，适合分页的业务列表再增加触底上拉分页；不因页面再次显示自动请求，不使用定时轮询。通讯录是明确的全量加载例外，不分页（2026-10-13）。
  • 移动端通讯录不限制部门范围，一次性返回全部状态正常、未删除的用户，并排除当前登录用户和超级管理员；移动端基于全量结果进行本地搜索（2026-10-13，取代部门范围及服务端分页方案）。
  • 移动端工单权限不依赖 PC 的 ops:workOrder:query：我的工单按创建人、责任人、核验人以及有派单权的待派单池取数，并叠加用户部门自身/祖先 101、102、103 对应设备父类型 1/2/3（共同包含 4）的公司范围；device_id 为空时创建人可见，派单后责任人和核验人按明确指派可见，其他派单人不可见。待办进一步按当前角色与状态收窄。流程权限统一为 ops:workOrder:process（接单/处置/提交验收/申请延期）和 ops:workOrder:audit（验收/延期审核），派单仍为 ops:workOrder:dispatch；派单候选责任人/核验人必须分别具有 process/audit 权限（2026-10-13）。
  • work_order.dept_id 已废弃，工单归属和可见性不得再依赖该字段；PC /api/ops/workOrder 列表及状态统计对普通用户统一按 create_by=当前用户 OR receive_user=当前用户 OR verify_user=当前用户 过滤，超级管理员不受限制（2026-10-13）。

  • 工单处置仅允许“已接单(2)”和“延期中(6)”状态执行并进入“处理中(3)”；已经处于“处理中”的工单不得重复执行工单处置，应继续申请延期或提交验收（2026-10-13）。

  • 报警清单顶部展示蓝色“报警总数”、红色“监测异常”、绿色“监测已恢复”三张卡片；仅增加统计区，保留原查询、表格和分页。统计按当前查询范围的全部事件计数，监测恢复不等同于工单处置完成（2026-09-24）。

  • 报警审核、清单、提醒三个页面及其 utils、styles 统一放在 src/views/subSystem/alarm/common；详情、历史等共享组件继续保留在 alarm 根目录。后端菜单组件白名单、初装及增量 SQL 同步新路径，路由 path 与 query 不变（2026-09-24）。

  • 告警表 alarm_data 不再存储设备名称、设备类型、处理时间、处理人、处理备注及通用 remark（2026-10-10）。报警描述改为新增时按指标名称与触发阈值固化到 alarm_content，前端直接展示该字段；名称和类型从设备台账查询，处理状态仍使用 alarm_status，操作日志独立保留。

  • 采用仓库原生 AGENTS.md + memory/ 方案。

  • 直接在当前项目目录维护记忆库，不创建额外 worktree。

  • 记忆库只使用 Markdown，不参与前端运行时，不新增 npm 依赖。

  • 前后端 Issue 均通过内网 Gogs 网页低频维护，不假定 CLI 或 API 集成。

  • Git 提交信息统一使用中文，说明改动目的与范围；一次提交只承载一个主题；用户未明确要求时不推送。

  • 工程技能采用默认 triage 标签：needs-triage、needs-info、ready-for-agent、ready-for-human、wontfix。

  • 前端领域文档采用单上下文布局；后端 E:\pipe-ner-server 采用按 Maven 模块划分的多上下文布局。

供水前端约定

  • 供水动态菜单组件路径统一使用 waterSupply/facility/*、waterSupply/device/*、waterSupply/monitoring/*、waterSupply/monitorAlarm/*。
  • 业务菜单仍由 /getRouters 动态下发；前端组件入口存在不等于角色已经获得对应 sys_menu 权限。
  • GIS 第一阶段使用后端 GeoJSON 做分类、点线分布与详情联动，后续接入真实底图时保持接口和页面名称不变。
  • 供水报警与工单前端统一使用唯一接单责任人；无手机号不阻断派单。
  • 供水、排水、燃气、窨井共用统一工单业务流程，系统展示范围由关联设备类型过滤；前端优先复用既有 REST 接口，不因页面入口创建平行工单生命周期。
  • 工单系统归属以关联设备类型树稳定业务编码判定；/api/work-order 是跨系统规范 API，旧入口只做兼容适配；统一工单继续采用数据库状态机和统一日志语义。
  • 2026-09-28 #66：供水报警管理恢复供水专属只读分析页（报警流水、四级趋势、报警台账与分类占比），菜单仍沿用后端下发的路径，仅在前端按供水 rootTypeId 解析到独立页面；排水仍使用公共简化列表。统一报警 API 补充设备报警状态与后端推导的四态展示状态（含误报警），不恢复旧供水 ledger 接口。
  • 报警管理侧重只读态势与台账；四子系统报警审核共用 src/views/subSystem/alarm/common/audit.vue，sys_menu.path 均为 alarmAudit，菜单 query.rootTypeId 按设备类型树隔离，燃气再限定 warning_code。确认报警创建待派单工单但不改设备状态；工单后续操作仍在统一工单页。此约定取代早期“审核页承载工单全流程/误报解除”的设计。
  • 报警继续使用 alarm_level：1～4 为一级～四级报警，一级最严重；audit_status 独立于 alarm_status。本次数据库脚本不迁移历史数据，不引入 source_key；alarm_log.log_id 使用 Kingbase int8 和独立序列 alarm_log_id_seq。
  • 报警运营共用 alarm/common/remind.vue、alarm/common/list.vue，排水研判与 GIS 为 drainage/alarm/analysis.vue、drainage/alarm/alarmGIS.vue；GIS 菜单 path 为 drainageAlarmGIS，详情无周边环境页签。现有菜单 2139/2140/2141/2143/2117 精确更新，供水 root=1、排水 root=2；后端校验授权菜单后查根及后代，运营读取与审核授权分开。供水 GIS 最新改为复制排水页面至 waterSupply/alarm/alarmGIS.vue（含配套 SCSS），菜单 2120 的 path=waterSupplyAlarmGIS、query={"rootTypeId":1}、perms=alarm:operations:list；旧地图页面、模型及专用地图/台账补全/详情/历史接口删除，首页地图取数也使用统一 /api/alarm/map。地图与曲线允许供水/排水，仍校验授权菜单及设备类型树；执行 migration_water_supply_alarm_gis.sql 后重新登录（2026-09-24 最新要求，取代保留旧供水 GIS 的决定）。
  • alarm_data.alarm_no 改由后端程序新增时生成 BJyyyyMMddHHmmss 加 4 位随机数（北京时间），覆盖请求带入的号码，普通更新不改号；不使用数据库赋号触发器/默认值/序列，保留唯一索引、不回填旧数据。管理端新增/演练及采集新增都赋号，采集复用与恢复不改号。相关列表首列展示报警单号，转工单创建日志使用该号；报警触发和采集自动恢复由 Java 在同事务记报警日志，不依赖自定义函数/触发器。研判仅使用真实采样，日/月均聚合原始有效值，不补零；没有数值数据源的指标明确提示无曲线（2026-09-24 用户最新调整，替代数据库生成及雪花 ID 约定）。
  • 报警确认只写一条审核日志，描述包含选填意见及“已转工单（实际工单号）”；关联工单和工单操作不再单独写 alarm_log，仍保留正常 work_order_log。人工日志使用 sys_user.nick_name；审核页与详情页共用 AlarmHistory.vue，按时间、同一时间按 ID 倒序，日期分组样式参考 dispose.vue，保留图片预览。按最新要求，zksy-system 与 zk-api-service 各自定义 AlarmLogOperTypeEnum（0 触发/1 确认/2 误报/3 处理），两份值保持一致，不新增共享模块，移除工单相关类型，不删除旧类型历史行（2026-09-24）。
  • 报警审核附件只支持 JPG/JPEG/PNG 图片（最多 5 张、单张 10 MB），前后端禁止 PDF；处置记录以缩略图展示，点击查看大图，可切换同条记录的多张图片。
  • 报警详情的监测状态、审核结果、处置状态采用紧凑横排“普通字重标签 + 小号浅色状态标记”，不使用灰底大卡片或加粗标签；状态文本仍来自接口，处置颜色复用工单字典（2026-09-24 截图样式要求）。
  • 供水首页保留报警态势/趋势/占比图，使用统一 /api/alarm/dashboard（rootTypeId=1、days默认7，后端范围校验），不引用已删除的 getAlarmLedgerDashboard 或旧 /waterSupply/alarm/ledger/dashboard。后端按全量授权数据聚合，仅趋势限制日期，不用分页明细推算总量（2026-09-24 修复）。
  • 报警提醒服务固定只查 alarm_status=0，页面不提供“报警清单”操作。报警清单时间条件叫“报警时间”，设备提示“请输入设备编码/名称”，移除审核结果筛选但保留表格结果列。GIS 曲线选项和研判下拉仅展示 actual_value 非空事件（0 有效）；地图点位、报警历史不受此限制，研判通过 actualValueOnly=true 后端先过滤再分页，无实际值深链接不能重新加入下拉（2026-09-24）。
  • 排水 GIS 地图接口固定只查 alarm_data.alarm_status=0，前端不提供监测状态筛选，设备编码/名称和等级筛选使用左标签右控件；设备列表、地图点位、等级统计同口径，详情报警记录保留历史。统计中灰色“报警设备”位于数量前，去掉右上角视图文案及详情底部状态说明（2026-09-24）。
  • 排水 GIS 样式参考 prd/outputs/alarm-gis.html：顶部筛选/等级统计、左侧设备列表、大地图及覆盖式详情抽屉，打开详情不挤占地图。统计展示当前结果的设备数，不是报警事件总数；沿用红橙蓝绿等级色、真实 GisMapCanvas/API 和框架分页。详情仅监测曲线、报警记录、设备信息，数值快照明确标注为触发值，不使用原型合成数据或周边环境内容（2026-09-24）。
  • 报警处置历史日期标题：当天只显示“今天”，前一天只显示“昨天”，不附加日期；同年其他日期显示“M月D日”，跨年保留年份。按本地日历日判断，悬停保留完整日期，每条操作仍显示时分秒，不改变倒序规则（2026-09-24 最新要求）。
  • 报警实际值为空时不展示实际值/阈值行，0 仍正常展示；审核转工单的 work_order.order_desc 保存根据报警信息生成的故障描述，审核意见单独保存在报警日志中。
  • 报警审核意见选填，最多 500 字，确认报警和误报警均允许不填，审核结果仍必选。正常关闭审核弹窗或切换路由不再弹出放弃确认；上传、提交进行中仍保留退出保护。此约定取代早期意见必填和未保存退出需确认的交互（2026-09-24）。
  • 普通手动建单和隐患转工单取消同设备未办结工单限制；报警转工单仅按设备主键 + alarm_data.warning_code 保证一个未办结工单（0/1/2/3/4/6），5 已结案和 7 已取消可释放名额。不同编码不互斥，报警恢复不等于工单办结；查重在设备行锁保护的建单事务中完成，缺失报警编码时明确报错，不按显示名称替代。旧“同设备所有工单互斥”规则不再适用（2026-09-24）。
  • 日常巡检和设备保养工单由其他业务系统创建及首次派发；派给当前用户后可以在供水工单总览继续处置。
  • 设备报警状态、报警记录状态和工单处置状态必须分别展示，不得互相替代。
  • 管理端统一工单生命周期采用数据库与前端一致的 0–7 契约（0 待派单/1 待接单/2 已接单/3 处理中/4 待验收/5 已结案/6 延期中/7 已取消）；终态仅已结案和已取消，延期中是处理旁路。验收驳回是“待验收(4)回退到处理中(3)”的动作而非状态。调用方必须按接口契约解释状态编码并以状态名展示。三仓共识见本仓 docs/domain/work-order-lifecycle.md。
  • 相关页面采用蓝白运行指挥台风格；一级至四级报警依次使用红、橙、蓝、绿，供水菜单全部配置图标。
  • 详细设计见 docs/design/2026-08-22-water-supply-work-order-ui.md。

产品级决策

  • 预警联动系统事件六状态统一颜色：DRAFT 草稿灰、PENDING 待接收黄、RECEIVED 已接收蓝、PROCESSING 处置中橙、HANDLED 已处置紫、CLOSED 已解除绿。所有事件状态标签和统计图表复用 lifeCompany/warningStatus.js，禁止各页面按数据位置自行分配状态色（2026-10-15）。
  • 预警事项关联为可选项，允许人工新增或采集生成的预警不关联事项直接发布；缺少匹配事项不能阻断草稿留存或发布（2026-09-29 用户明确确认）。
  • 预警清单和系统预警的等级下拉统一为一至四级，共用 alert_level；原因库和编码生成同步使用该字典。2026-09-29 开发库已补齐原缺少的四级，现有等级标签保留。
  • 正式产品定位为“城市地下管网及设施建设改造智能化系统项目”软件平台中的“地下管网管控平台”；供水交付单元为“供水管网安全运行监测系统”，由本前端与 E:\pipe-ner-server\pipe-network-service 后端共同构成。
  • KingbaseES 是生产和最终验收唯一数据库真相源；PostgreSQL 仅在无法避免时用于兼容性验证。
  • 供水整体开发按业务纵向切片推进，既有接口可复用时优先复用；真实接口失败不得回退到随机模拟数据。
  • 前后端保持独立仓库和独立构建，以版本化 REST 契约、真实登录态 E2E 和 KingbaseES 集成验收作为集成门禁。
  • 工单处置图片采用 MinIO + KingbaseES 附件元数据；现有工单图片 URL 字段继续兼容，新图片按处理前/处置后阶段展示。